DevIL segfault, issues with png's, bmp's - c++

I am on mingw (gcc version 4.5.2).
I get a segfault when opening certain files, including PNGs and BMPs. It was working fine on a 128x128 PNG but when I started testing with larger files I started getting a segfault. There are no issues with the TGA format, though. I know the library works for the most part, but not knowing whether it will decide to crash and burn like this is not good.
gdb does not give me any hints about what's going on. I am able to compile DevIL from source, and I compiled a debug dll (--enable-debug for configure script) but it doesn't seem to support png (seems like I need to get a png12 library) but it doesn't get me very far.
I am trying to open a ~2MB BMP I made in GIMP. I run it through GDB and it sometimes will segfault but other times it warns of some stuff happening on the heap (lots of stuff i've never seen before). Here's a gdb run dump. All of the lines beginning with %%% are the output that is specific to my program, the rest comes from gdb.
$ gdb ./entropy_unittest_disp.exe loadpngdisplay
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp
\game/./entropy_unittest_disp.exe...done.
c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp\game/loadpngdisplay:
No such file or directory.
(gdb) r
Starting program: c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp\ga
me/./entropy_unittest_disp.exe
[New Thread 23284.0x5bb4]
%%%UNIT TEST BUILD: INTERNAL USE ONLY. DO NOT DISTRIBUTE
%%%Compiled on Sep 11 2011 at 09:45:38
%%%argc = 1: Main.cpp:119
%%%argv:
%%%0: c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp\game/./entropy_un
%%%ittest_disp.exe
%%%←[36mStarting Test ilWritePng, at Image.cpp:8←[0m
%%%rm: cannot lstat `output_il.png': No such file or directory
%%%ilGetError() = 1292: Image.cpp:25
%%%Completed Test ilWritePng in 0.033 seconds
%%%←[36mStarting Test loadPNGDisplay, at Image.cpp:31←[0m
[New Thread 23284.0x445c]
[New Thread 23284.0x1fd8]
[New Thread 23284.0x1424]
%%%Number of Joysticks detected: 2
%%%Opening Joystick: Harmonix Guitar for Xbox 360 (Controller)
[New Thread 23284.0x526c]
[New Thread 23284.0x5a70]
[New Thread 23284.0x1ae8]
[New Thread 23284.0x5908]
[New Thread 23284.0x5974]
%%%Using GLEW 1.5.8
%%%OpenGL Vendor: NVIDIA Corporation
%%%OpenGL Renderer: GeForce GTX 260/PCI/SSE2
%%%OpenGL Version: 3.3.0
warning: HEAP[entropy_unittest_disp.exe]:
warning: Invalid address specified to RtlFreeHeap( 00350000, 04000000 )
Program received signal SIGTRAP, Trace/breakpoint trap.
0x772e0475 in ntdll!TpWaitForAlpcCompletion ()
from C:\Windows\system32\ntdll.dll
(gdb) where
#0 0x772e0475 in ntdll!TpWaitForAlpcCompletion ()
from C:\Windows\system32\ntdll.dll
#1 0x0028f510 in ?? ()
#2 0x772a29c0 in ntdll!RtlCopyExtendedContext ()
from C:\Windows\system32\ntdll.dll
#3 0x03fffff8 in ?? ()
#4 0x772e14cf in ntdll!TpQueryPoolStackInformation ()
from C:\Windows\system32\ntdll.dll
#5 0x00350000 in ?? ()
#6 0x7729ab3a in ntdll!AlpcMaxAllowedMessageLength ()
from C:\Windows\system32\ntdll.dll
#7 0x00350000 in ?? ()
#8 0x77243472 in ntdll!RtlLargeIntegerShiftRight ()
from C:\Windows\system32\ntdll.dll
#9 0x03fffff8 in ?? ()
#10 0x766398cd in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
#11 0x00350000 in ?? ()
#12 0x6180129c in _mm_free (aligned_ptr=0x8230020)
at c:/mingw/bin/../lib/gcc/mingw32/4.5.2/include/mm_malloc.h:71
#13 0x61801370 in DefaultFreeFunc (ptr=0x8230020)
at ./../src-IL/src/il_alloc.c:127
#14 0x618012ee in ifree (Ptr=0x8230020) at ./../src-IL/src/il_alloc.c:99
#15 0x618149f8 in iPreCache (Size=592128) at ./../src-IL/src/il_files.c:550
#16 0x618148a2 in iReadFile (Buffer=0x8100017, Size=1, Number=2313)
at ./../src-IL/src/il_files.c:499
#17 0x61808cf5 in ilReadUncompBmp (Header=0x28f829)
at ./../src-IL/src/il_bmp.c:486
#18 0x61808410 in iLoadBitmapInternal () at ./../src-IL/src/il_bmp.c:250
#19 0x618082f3 in ilLoadBmpF (File=0x766d2960) at ./../src-IL/src/il_bmp.c:199
#20 0x618082ba in ilLoadBmp (FileName=0x4c25f1 "folder.bmp")
at ./../src-IL/src/il_bmp.c:184
#21 0x61830bf0 in ilLoadImage (FileName=0x4c25f1 "folder.bmp")
at ./../src-IL/src/il_io.c:1827
#22 0x0040f66c in SDLSystemloadPNGDisplayHelper::RunImpl (this=0x28fc10)
at Image.cpp:40
#23 0x00461e74 in UnitTest::ExecuteTest<SDLSystemloadPNGDisplayHelper> (
testObject=..., details=...) at ../include/UnitTest++/ExecuteTest.h:25
#24 0x0040f2cd in TestSDLSystemloadPNGDisplay::RunImpl (this=0x4e5cf8)
at Image.cpp:31
#25 0x00463023 in UnitTest::ExecuteTest<UnitTest::Test> (testObject=...,
details=...) at src/ExecuteTest.h:25
#26 0x0044198d in UnitTest::Test::Run (this=0x4e5cf8) at src/Test.cpp:34
#27 0x00441d9a in UnitTest::TestRunner::RunTest (this=0x28fedc,
result=0x3517f0, curTest=0x4e5cf8, maxTestTimeInMs=0)
at src/TestRunner.cpp:61
#28 0x00466b7e in UnitTest::TestRunner::RunTestsIf<UnitTest::True> (
this=0x28fedc, list=..., suiteName=0x0, predicate=..., maxTestTimeInMs=0)
at ../include/UnitTest++/TestRunner.h:40
#29 0x004014e3 in UnitTest::RunAllTestsVerbose () at Main.cpp:72
#30 0x0040167d in main (argc=1, argv=0x3531d8) at Main.cpp:126
(gdb) c
Continuing.
warning: HEAP[entropy_unittest_disp.exe]:
warning: Invalid address specified to RtlFreeHeap( 00350000, 04000000 )
Program received signal SIGTRAP, Trace/breakpoint trap.
0x772e0475 in ntdll!TpWaitForAlpcCompletion ()
from C:\Windows\system32\ntdll.dll
(gdb) c
Continuing.
warning: HEAP[entropy_unittest_disp.exe]:
warning: Invalid address specified to RtlFreeHeap( 00350000, 04000000 )
Program received signal SIGTRAP, Trace/breakpoint trap.
0x772e0475 in ntdll!TpWaitForAlpcCompletion ()
from C:\Windows\system32\ntdll.dll
(gdb)
Continuing.
warning: HEAP[entropy_unittest_disp.exe]:
warning: Invalid address specified to RtlFreeHeap( 00350000, 04000000 )
Program received signal SIGTRAP, Trace/breakpoint trap.
0x772e0475 in ntdll!TpWaitForAlpcCompletion ()
from C:\Windows\system32\ntdll.dll
(gdb)
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 23284.0x5974]
0x05064225 in nvoglv32!DrvGetProcAddress ()
from C:\Windows\SysWOW64\nvoglv32.dll
(gdb)
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x05064225 in nvoglv32!DrvGetProcAddress ()
from C:\Windows\SysWOW64\nvoglv32.dll
(gdb)
Continuing.
Program exited with code 030000000005.
(gdb)
The program is not being run.
(gdb) r
Starting program: c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp\ga
me/./entropy_unittest_disp.exe
[New Thread 23428.0x49b8]
%%%UNIT TEST BUILD: INTERNAL USE ONLY. DO NOT DISTRIBUTE
%%%Compiled on Sep 11 2011 at 09:45:38
%%%argc = 1: Main.cpp:119
%%%argv:
%%%0: c:\Users\Steven\Dropbox\Programming\entropy_p5_makefile\cpp\game/./entropy_un
%%%ittest_disp.exe
%%%←[36mStarting Test ilWritePng, at Image.cpp:8←[0m
Program received signal SIGSEGV, Segmentation fault.
0x7723dfc4 in ntdll!LdrWx86FormatVirtualImage ()
from C:\Windows\system32\ntdll.dll
(gdb) where
#0 0x7723dfc4 in ntdll!LdrWx86FormatVirtualImage ()
from C:\Windows\system32\ntdll.dll
#1 0x1f002150 in ?? ()
#2 0x00000000 in ?? ()
(gdb)
the test ilWritePng is actually just having it write a .tga image file. That test works fine with the release dll (md5 = 59E291838AE2C88F5F71108E4845A84B) but this debug build I compiled has more issues.
I was so happy when I skimmed the doc and got DevIL up and running in like 10 minutes. I figured it was going to save me so much work...
This is making me start to wonder if I should just implement my own image file format (I would use PPM binary and shove it through a compression stream).
edit: source code:
#include "Texture.h" // for Pixel struct
#include "Script.h" // for lua (quick and dirty shell access)
TEST_FIXTURE(ILSystem, ilWritePng) { // ILSystem calls ilInit(), ilShutDown() in ctor, dtor respectively
ILuint image;
ilGenImages(1,&image);
CHECK(ilGetError()==0);
ilBindImage(image);
Pixel pixels[128*128];
for (int i=0;i<128;++i) { for (int j=0;j<128;++j) {
Pixel &p = pixels[i*128+j];
p.b = 0; p.g = i; p.r = j; p.a = 0xff;
}} // neat and simple test image, a greenish purplish gradient type thing.
CHECK(ilTexImage(128,128,1,4,IL_BGRA, IL_UNSIGNED_BYTE,pixels));
CHECK(ilGetError()==0);
{
LuaSystem l;
l.dostring("os.execute(\"rm output_il.tga\")"); // delete that file
}
ilSaveImage("output_il.tga");
PRINT_INT(ilGetError());
}
#ifdef LOAD_DISPLAY
#include "SDLOGL.h"
#include "Texture.h"
TEST_FIXTURE(SDLSystem, loadPNGDisplay) { // takes care of initing SDL and opengl context
ILSystem s; // RAII = peace of mind
// i can't use two fixtures in one unittest. but this does the same thing anyway.
ILuint image;
CHECK(ilGetError()==0);
ilGenImages(1,&image);
CHECK(ilGetError()==0);
ilBindImage(image);
CHECK(ilGetError()==0);
ilLoadImage("folder.bmp");
CHECK(ilGetError()==0);
ILubyte *pixelData = ilGetData(); CHECK(pixelData);
CHECK(ilGetError()==0);
GLuint tex = loadImage32(pixelData,ilGetInteger(IL_IMAGE_WIDTH),ilGetInteger(IL_IMAGE_HEIGHT),0);
// i do not know exactly how its encoded. but it seems like when loading pngs it is in RGBA format
PRINT_INT(ilGetInteger(IL_FORMAT_MODE));
CHECK(ilGetError()==0);
initOrthoRender();
drawTexture(tex);
CHECK(glGetError()==0);
SDL_GL_SwapBuffers();
SLEEP(500);
}
#endif //LOAD_DISPLAY

Related

How to debug a QString causing a bus error?

I have a Raspberry Pi 3B+ with my Qt code on it (Qt 5.12.5). When I run my code, it randomly crashes with a Bus Error after a few hours. I am not sure how to work out the exact cause. I cross compile on Ubuntu for the RPi using the latest Raspberry Pi OS (2020-05-27).
The core dump (I have replaced some irrelevant parts with ...)
pi#raspberrypi: $ gdb TEST core
GNU gdb (Raspbian 8.2.1-2) 8.2.1
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from TEST...done.
[New LWP 1233]
...
[New LWP 1226]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./TEST'.
Program terminated with signal SIGBUS, Bus error.
#0 0x755b5b7c in QString::arg(long long, int, int, QChar) const () from /usr/local/qt5pi/lib/libQt5Core.so.5
[Current thread is 1 (Thread 0x6feff440 (LWP 1233))]
(gdb) bt full
#0 0x755b5b7c in QString::arg(long long, int, int, QChar) const () at /usr/local/qt5pi/lib/libQt5Core.so.5
#1 0x0001c0bc in QString::arg(int, int, int, QChar) const (this=0x6fefdc78, a=12, fieldWidth=0, base=10, fillChar=...) at ../raspi/qt5pi/include/QtCore/qstring.h:976
#2 0x00039ff8 in StageState::getStateString() (this=0x6fefdf00) at ../TEST/stage.h:35
...
#7 0x00142124 in TEST::timerExpired() (this=0x7ecd4708) at ../TEST/TEST.cpp:51
__PRETTY_FUNCTION__ = "void TEST::timerExpired()"
locker = {val = 2127384345}
#8 0x0015c188 in TEST::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x7ecd4708, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0x6fefe9d8) at moc_TEST.cpp:122
_t = 0x7ecd4708
#9 0x75722b08 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#10 0x75730c1c in QTimer::timeout(QTimer::QPrivateSignal) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#11 0x75730fc8 in QTimer::timerEvent(QTimerEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#12 0x75724194 in QObject::event(QEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#13 0x768c6b88 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#14 0x768ce29c in QApplication::notify(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#15 0x759b62ec in QCoreApplication::self () at /usr/local/qt5pi/lib/libQt5Core.so.5
(gdb)
../TEST/stage.h:35 refers to this code:
return QString("text %1").arg(aInt);
Possible causes and fixes I am considering:
To me, from the stack trace, it looks like the crashes are occurring inside QString, possibly due to a Qt bug? However I am not sure. I can try a newer version of Qt.
I am also using a QTimer in a thread, maybe this could cause a issue, accessing a object from other threads? I am already using QMutex. I could instead only use the gui thread short term and test if crashes still occur.
Searching online, I found a comment to look a the dmesg output (below), maybe my MicroSD card is dying? I am waiting for a new one to arrive.
Anything else?
pi#raspberrypi:~ $ dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.44-v7+ (dom#buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1320 SMP Wed Jun 3 16:07:06 BST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
...
[ 17.898294] Bluetooth: BNEP filters: protocol multicast
[ 17.898313] Bluetooth: BNEP socket layer initialized
[16092.809350] Alignment trap: not handling instruction e1903f9f at [<755b5b78>]
[16092.809367] 8<--- cut here ---
[16092.815191] Unhandled fault: alignment exception (0x001) at 0x6f577277
[16092.820865] pgd = 6aa8fcbe
[16092.826468] [6f577277] *pgd=3278c835, *pte=2812175f, *ppte=28121c7f
Here is another bus error that is similar but not quite the same as previously:
pi#raspberrypi:~/TEST/bin $ gdb TEST core
GNU gdb (Raspbian 8.2.1-2) 8.2.1
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from TEST...done.
[New LWP 767]
...
[New LWP 763]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./TEST'.
Program terminated with signal SIGBUS, Bus error.
#0 0x7568d470 in QString::fromAscii_helper(char const*, int) () from /usr/local/qt5pi/lib/libQt5Core.so.5
[Current thread is 1 (Thread 0x709bf440 (LWP 767))]
(gdb) bt
#0 0x7568d470 in QString::fromAscii_helper(char const*, int) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#1 0x75830da4 in () at /usr/local/qt5pi/lib/libQt5Core.so.5
#2 0x0001c030 in QString::QString(char const*) (this=0x709be71c, ch=0x15fa88 "[0-9| ]{3}") at ../raspi/qt5pi/include/QtCore/qstring.h:700
#3 0x00029da8 in Measurement::doesRececivedDataFormatMatchRegex(QString) (this=0x709be7f4, receivedData=...) at ../TEST/Measurement.h:103
...
#12 0x7580c58c in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#13 0x7580c90c in QSocketNotifier::event(QEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#14 0x769a2b88 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#15 0x769aa29c in QApplication::notify(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#16 0x75a922ec in QCoreApplication::self () at /usr/local/qt5pi/lib/libQt5Core.so.5
Edit: added getStateString() and doesRececivedDataFormatMatchRegex() functions
QString getStateString() {
switch (state) {
case StageState::AEnum:
return QString("text %1").arg(aInt);
...
default:
return QString("Unknown");
}
}
bool Measurement::doesRececivedDataFormatMatchRegex(QString receivedData)
{
QRegExp regExp("[0-9| ]{3}");
return receivedData.indexOf(regExp) != -1;
}

Boost iostreams long time to open memory mapped file

When I call open on a boost::iostreams::mapped_file_source my program hangs for around two minutes. I tried attaching gdb to the process at this point and the backtrace shows
(gdb) backtrace
#0 0x00007f779226687a in mmap64 () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7793c60f58 in boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#2 0x00007f7793c61028 in boost::iostreams::detail::mapped_file_impl::map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#3 0x00007f7793c614d2 in boost::iostreams::detail::mapped_file_impl::open(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#4 0x00007f7793c6168e in boost::iostreams::mapped_file_source::open_impl(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path> const&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#5 0x0000000000e07f86 in boost::iostreams::mapped_file_source::open<boost::iostreams::detail::path> (this=this#entry=0x1db63f8, p=...) at /usr/include/boost/iostreams/device/mapped_file.hpp:406
#6 0x0000000000e08011 in boost::iostreams::mapped_file_source::open<boost::filesystem::path> (this=this#entry=0x1db63f8, path=..., length=length#entry=18446744073709551615, offset=offset#entry=0)
at /usr/include/boost/iostreams/device/mapped_file.hpp:416
Why is the call to open so slow here? Shouldn't it return quickly here?

Why mingw+gdb cannot show backtrace correctly from inside a sigsegv handler?

I'm debugging a process that runs really slow when is executed from gdb on Windows (mingw32), so I decided to run it until it crash without gdb, and then to attach the debugger. I've installed a signal handler for sigsegv that shows its pid and waits, so when I see the message I load gdb and use the "attach" command with that pid. The problem is that gdb shows me an useless backtrace at that point. Here's an example:
void my_sigsegv_handler(int) {
std::cerr << "Segmentation fault! pid=" << GetCurrentProcessId();
std::cin.get(); // wait for gdb
}
int main() {
signal(SIGSEGV,my_sigsegv_handler);
int *p = 0;
std::cout << *p; // boom!
}
Compiled with "mingw32-g++ -g -O0", output from gdb's command "bt" (after selecting the proper thread) is:
#0 0x764e73ea in ?? ()
#1 0x7646f489 in ?? ()
#2 0x75edc3b3 in ?? ()
#3 0x75edc2bc in ?? ()
#4 0x75edc472 in ?? ()
#5 0x00415502 in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::uflow() ()
#6 0x00434f32 in std::istream::get() ()
#7 0x004016d5 in my_sigsegv_handler () at C:\Users\usuario\zinjai\sin_titulo.cpp:8
#8 0x004010f9 in _gnu_exception_handler (exception_data=0x28fa88) at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:137
#9 0x76469d57 in ?? ()
#10 0x77100727 in ?? ()
#11 0x770c9d45 in ?? ()
#12 0x00000000 in ?? ()
Notice that this example does not corrupt stack when generating the segfault. Actualy, I can debug it anyway, just continuing execution. If I press enter the signal handler finishes, returns to the place where it was generated (main function), and the problem is not solved, but this time gdb is there to catch it. But I'd like to now how does it really works.
If I use the same method in gnu/linux I can see what I want to see here:
#5 0x00007f6809bf349e in std::istream::get() () from /usr/lib64/libstdc++.so.6
#6 0x00000000004008cd in my_signal_handler () at /home/zaskar/.zinjai/sin_titulo.cpp:6
#7 <signal handler called>
#8 0x00000000004008f9 in main (argc=1, argv=0x7fffa0613108) at /home/zaskar/.zinjai/sin_titulo.cpp:11
So the question is, why gdb cannot show me the correct backtrace from withing the signal handler? Or what am I doing wrong? Is there any better way to solve it?

GDB: stepping into a library

Runnning my application I get a Segmentation fault. I ran gdb to check where my code was failing but I get the following output:
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
(gdb) bt
#0 0x39ca8000 in ?? ()
#1 0xb7d5df9a in sc_core::sc_port_base::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#2 0xb7d5e104 in sc_core::sc_port_registry::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#3 0xb7d5e13e in sc_core::sc_port_registry::elaboration_done() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#4 0xb7dc669d in sc_core::sc_simcontext::elaborate() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#5 0xb7dc8567 in sc_core::sc_simcontext::initialize(bool) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#6 0xb7dc8b19 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#7 0xb7dc9708 in sc_core::sc_start(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
#10 0xb7dbc698 in sc_elab_and_sim () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#11 0xb7d522e7 in main () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#12 0xb7a2e4d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#13 0x08054da1 in _start ()
As you can see, everything comes from a library, except the 'main' call and 'start',where I set breakpoints, but they fail immediately there. I mean:
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
...
(gdb) br /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
Breakpoint 2 at 0x8055584: file /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h, line 608.
(gdb) r
Starting program: /home/guest/Solutions/eln/systemc-ams/module_pfn
...
Breakpoint 2, sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
608 sc_start( sc_time( duration, time_unit ) );
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
And we go back to the start.
I am not able to understand where this is failing. I see there is the name of the place in which this is failing: sc_core::sc_port_base::complete_binding() and I have access to the cpp where this function can be found, but only in the source files (not the library). The problem is that I would really like to go step by step through that code, is it possible?
Thanks :)
Thanks guys!
I used a library with debug info and now I can go through the library code.

Using Gdb debugger, how should I proceed to find out the cause of "Program terminated with signal 11, Segmentation fault."

Here is the backtrace of gdb,
Program terminated with signal 11, Segmentation fault.
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
(gdb) bt
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
#1 0x08221d5d in sigc::bound_mem_functor0<bool, videoScreen>::operator() (this=0xb1c04714)
at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787`enter code here`
#2 0x08221d76 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, videoScreen> >::operator() (this=0xb1c04710)
at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#3 0x08221d96 in sigc::internal::slot_call0<sigc::bound_mem_functor0<bool, videoScreen>, bool>::call_it (rep=0xb1c046f8)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
#4 0xb7b1ed35 in ?? () from /usr/lib/libglibmm-2.4.so.1
#5 0xb73c6bb6 in ?? () from /usr/lib/libglib-2.0.so.0
#6 0xb28ff1f8 in ?? ()
#7 0xb647479c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#8 0xb73c6446 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9 0xb73c97e2 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0xb3d11af8 in ?? ()
#11 0x00000000 in ?? ()
I figured out the line of crash,here is the code around that line.
1:currPicLoaded = 1;
2:int status = -1;
3:zoomedPicWidth = drawVideo1->get_width();
I figured out that above line is 3 is the cause of crash, but this line execute 5 times before crash.So I do not know why it does crash at 6th time.
PS : Above line of code is with in a thread which run continuously.
Any help is more than welcome :)
how should I proceed
Your very first step should be to find out which instruction caused the SIGSEGV. Do this:
(gdb) x/i $pc
The most likely cause is that your drawVideo1 object is either dangling (has been deleted), or is corrupt in some other way.
Since you are apparently on Linux (you didn't say, but you should always say), the first tool to reach for for debugging "strange" problems like this is Valgrind.