Segfault during startup ...

[herbertp]

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe9eee700 (LWP 25140)]
[New Thread 0x7fffdf0c1700 (LWP 25141)]
[New Thread 0x7fffde8c0700 (LWP 25142)]
[New Thread 0x7fffddf04700 (LWP 25143)]

Thread 1 "alterpcb-tlines" received signal SIGSEGV, Segmentation fault.
0x000000000046bc80 in MaterialDatabase::LoadFile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) ()

(gdb) where
#0 0x000000000046bc80 in MaterialDatabase::LoadFile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) ()
#1 0x0000000000426d6b in MainWindow::LoadMaterials() ()
#2 0x000000000042b492 in MainWindow::MainWindow() ()
#3 0x000000000040b9fc in main ()

[rroohhh]

this seems to fix this problem, but I am not sure this is the root of the problem.

[MaartenBaert]

What did you do to trigger this bug? Did you change the materials file in some way? I'm not able to reproduce this. I tried running the program through Valgrind but it doesn't find anything either.

I don't see how the change to the hash table would help, that variable doesn't need to be initialized to INDEX_NONE because it is already going to be set in AddHash().

[herbertp]

Hello Maarten,

On Tue, Mar 26, 2019 at 02:20:15PM -0700, Maarten Baert wrote: What did you do to trigger this bug?

I built it on Mageia 6 with gcc 5.5.0. The result basically segfaults 9 out of 10 times, and when it doesn't segfault, it hangs.

Did you change the materials file in some way?

Nope, prestine git checkout.

I'm not able to reproduce this. I tried running the program through Valgrind but it doesn't find anything either.

No problem, I think 'we' already fixed it. apertus-open-source-cinema@8a5b0a9

I don't see how the change to the hash table would help, that variable doesn't need to be initialized to INDEX_NONE because it is already going to be set in AddHash().

We will send some pull requests once we have tested it more extensively. Thanks for the quick response, appreciated! All the best, Herbert

…

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #3 (comment)

[rroohhh]

I don't see how the change to the hash table would help, that variable doesn't need to be initialized to INDEX_NONE because it is already going to be set in AddHash().

yes I am also not really sure, but what happens on the hangs it, that in the FindAt loop i is zero and m_data[i].m_hashlink is zero aswell, but m_hasher.Equal(m_data[i], key) returns false and a infinite loop is entered.

[herbertp]

I forgot to mention, it doesn't seem to happen when compiled with gcc 8.3.1 on Mageia 6.

Best,
Herbert

[MaartenBaert]

Could this be a compiler bug? I've gone through the hash table implementation again and can't find the problem. Every possible path which adds an Entry to m_data has to go through AddHash which should initialize m_hashlink.

[rroohhh]

Yes that could very well be, however I don't know how one would verify that.