abrt version: 1.1.17 architecture: i686 Attached file: backtrace, 20573 bytes cmdline: 3Depict component: 3Depict Attached file: coredump, 38219776 bytes crash_function: wxWindowBase::TryValidator(wxEvent&) executable: /usr/bin/3Depict kernel: 2.6.35.11-83.fc14.i686 package: 3Depict-0.0.4-2.fc14 rating: 4 reason: Process /usr/bin/3Depict was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1299765261 uid: 500 How to reproduce ----- 1. crashed at startup... 2. 3. I was just playing with the application.
Created attachment 483867 [details] File: backtrace
Hello Daniel, Thanks for the report. I installed a fresh fedora VM matching your arch, but was unable to reproduce the problem. This may indicate a memory error in how I am using wx or in wx or gtk itself. Does this happen every time you launch the program? If you have the time, can you run the code through valgrind? To do this, install valgrind from the repository,then open a command line and rype "valgrind --track-origins=yes -- 3Depict". This should start examining the code for memory errors, and will dump them to your console. It will be quite slow (about 20x slower).
A thought occurs -- can you run "glxinfo | grep glx" ? Its possible that the window might fail due to missing 3D support. I don't have any mechanism to trap that, so it could segfault whilst trying to initalise the 3D view. Do other 3D applications work?
3Depict-0.0.4-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/3Depict-0.0.4-3.fc14
3Depict-0.0.4-3.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/3Depict-0.0.4-3.fc13
Hi again. I managed to disable my GLX support, and the program does indeed crash at startup. I have created a patch that fixes a crash (still won't run, but it will spit out an error to your console). However, the location of the crash is not the same as in your report. Nevertheless, the action of the code was undefined; so its possible that it is the same underlying problem. Maybe, maybe not. I have pushed an update-candidate for F13 & F14. You can enable the testing repository to try this update. https://fedoraproject.org/wiki/Updates-testing
Hello D. Haley. Thank you for your time. I ran valgrind --track-origins=yes -- 3Depict as you adviced me, and I found 6 errors. After that I installed 3Depict-0.0.4-3.fc14.i686.rpm and I could not run 3Depict anymore but valgrind --track-origins=yes -- 3Depict showed me no error, so I had to remove 3Depict and installed it again. After the installation, I found this error in terminal when I started the application: /root/.3Depict/config.xml:1: validity error : Validation failed: no DTD found ! <threeDepictconfig> ^ It seems like there is an error with the config.xml file. This was a problem from the beginning, but in the previous installation, 3Depict was not able to find config.xml at all.
The DTD error is not a problem -- I am not planning to write a DTD until version 0.1 of the program. Yes it still complains, but it does ignore the error and carry on. The config.xml file is created dynamically if it cannot be found using default settings, so is similarly not a problem. However, the exact output from valgrind for 0.0.4-2 would be useful if you can attach it. I have removed 0.0.4-3 from the testing repository as the GLX problem was still not resolved; I still need to look into how to fix this, as it is not clear. I believe *that* error is related to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575536
Hello D Haley "The DTD error is not a problem". I belive you're right. The valgrind command now opens 3Depict, which could not do that before. If it helps then, this is the result: valgrind --track-origins=yes -- 3Depict ==2742== Memcheck, a memory error detector ==2742== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2742== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2742== Command: 3Depict ==2742== ==2742== Conditional jump or move depends on uninitialised value(s) ==2742== at 0x3888630: wxGrid::Refresh(bool, wxRect const*) (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389D9FA: wxGrid::ClearSelection() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389DEFE: wxGrid::Init() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389E558: wxGrid::Create() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389EC3A: wxGrid::wxGrid(wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&) (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x810FACE: ??? (in /usr/bin/3Depict) ==2742== by 0x80959A3: ??? (in /usr/bin/3Depict) ==2742== by 0x809B2C8: ??? (in /usr/bin/3Depict) ==2742== by 0x4898947: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x4898A07: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x8084F6B: ??? (in /usr/bin/3Depict) ==2742== by 0x404BE35: (below main) (in /lib/libc-2.13.so) ==2742== Uninitialised value was created by a heap allocation ==2742== at 0x4006337: operator new(unsigned int) (vg_replace_malloc.c:214) ==2742== by 0x809596F: ??? (in /usr/bin/3Depict) ==2742== by 0x809B2C8: ??? (in /usr/bin/3Depict) ==2742== by 0x4898947: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x4898A07: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x8084F6B: ??? (in /usr/bin/3Depict) ==2742== by 0x404BE35: (below main) (in /lib/libc-2.13.so) ==2742== ==2742== Conditional jump or move depends on uninitialised value(s) ==2742== at 0x3888630: wxGrid::Refresh(bool, wxRect const*) (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389DA11: wxGrid::ClearSelection() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389DEFE: wxGrid::Init() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389E558: wxGrid::Create() (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x389EC3A: wxGrid::wxGrid(wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&) (in /usr/lib/libwx_gtk2u_adv-2.8.so.0.7.0) ==2742== by 0x810FACE: ??? (in /usr/bin/3Depict) ==2742== by 0x80959A3: ??? (in /usr/bin/3Depict) ==2742== by 0x809B2C8: ??? (in /usr/bin/3Depict) ==2742== by 0x4898947: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x4898A07: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x8084F6B: ??? (in /usr/bin/3Depict) ==2742== by 0x404BE35: (below main) (in /lib/libc-2.13.so) ==2742== Uninitialised value was created by a heap allocation ==2742== at 0x4006337: operator new(unsigned int) (vg_replace_malloc.c:214) ==2742== by 0x809596F: ??? (in /usr/bin/3Depict) ==2742== by 0x809B2C8: ??? (in /usr/bin/3Depict) ==2742== by 0x4898947: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x4898A07: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.8.so.0.7.0) ==2742== by 0x8084F6B: ??? (in /usr/bin/3Depict) ==2742== by 0x404BE35: (below main) (in /lib/libc-2.13.so) ==2742== /root/.3Depict/config.xml:1: validity error : Validation failed: no DTD found ! <threeDepictconfig> ^ ==2742== ==2742== HEAP SUMMARY: ==2742== in use at exit: 1,319,275 bytes in 10,198 blocks ==2742== total heap usage: 88,759 allocs, 78,561 frees, 41,820,383 bytes allocated ==2742== ==2742== LEAK SUMMARY: ==2742== definitely lost: 3,632 bytes in 53 blocks ==2742== indirectly lost: 13,188 bytes in 610 blocks ==2742== possibly lost: 860,731 bytes in 4,165 blocks ==2742== still reachable: 441,724 bytes in 5,370 blocks ==2742== suppressed: 0 bytes in 0 blocks ==2742== Rerun with --leak-check=full to see details of leaked memory ==2742== ==2742== For counts of detected and suppressed errors, rerun with: -v ==2742== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 154 from 13)
I think your patch, in some way trows the error that crash 3Depict, though the error is still there, but does not harm the application to crash, becouse you isolated that error. At this point, you were doing a good job. Keep it that way!
This should be fixed from 0.0.7, which is now an update-candidate for f15 and f16, and has been updated on the master git branch.
Closing, assumed that the last few upstream releases have fixed the problem.