On 2008-11-13, MacArthur, Ian (SELEX GALILEO, UK) <[EMAIL PROTECTED]> wrote:
>
>
>
>> what happened is that, all of a sudden, my app segfaults
>> always in some FLTK redraw function. It worked yesterday
>> evening but this morning, without me changing anything in
>> the code (really!) it started to segfault in linux (code
>> still works fine in windows). i tried to recompile fltk
>> (maybe some lib it depends on was updated and since i use a
>> self-made fltk-1.1.9 lib i thought that might have caused
>> this (my distribution ships 1.1.7 but i want 1.1.9)). but
>> it didnt help.
>
> Build a fltk lib with debugging enabled, then link to that, then launch
> your app from gdb and when it crashes, you can "bt" in the gdb console
> to see where, and why, it dies.
>
> Or, if you are running Eclipse, it can run the gdb session for you
> graphically, which is probably easier. Either way, once you have the app
> built with a debug lib (and NOT stripped at link time!) then you can see
> all the fltk symbols and so forth and find out why it faults.
>
>
> That said, it sounds like memory allocation or a mishandled pointer.
> It worked before, you say, but does not now, even though you did not
> change it - probably the OS has mapped things into RAM a bit differently
> this time, and now you are tripping up...
>
hehe, yeah! tripped up sounds like it. this is driving me
nuts! yesterday everything was fine, well almost, ...
so i tried to link against a debug lib of fltk but then it
segfaults before even starting, maybe because there are
some symbols missing:
$ LD_LIBRARY_PATH=/usr/lib/debug/usr/lib ldd ./prodatum
linux-gate.so.1 => (0xb7f14000)
libfltk.so.1.1 => /usr/lib/debug/usr/lib/libfltk.so.1.1 (0xb7e65000)
libportmidi.so.0 => /usr/lib/libportmidi.so.0 (0xb7e4c000)
libporttime.so.0 => /usr/lib/libporttime.so.0 (0xb7e49000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d56000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d31000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d26000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bd7000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7bbf000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7afb000)
/lib/ld-linux.so.2 (0xb7f15000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7af7000)
there are a few missing, look at whats linked normally:
$ ldd prodatum
linux-gate.so.1 => (0xb7f8d000)
libfltk.so.1.1 => /usr/lib/libfltk.so.1.1 (0xb7ecb000)
libportmidi.so.0 => /usr/lib/libportmidi.so.0 (0xb7ec5000)
libporttime.so.0 => /usr/lib/libporttime.so.0 (0xb7ec2000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7dcf000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7daa000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d9f000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c50000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c38000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7c34000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c30000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7c22000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7b3b000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7a78000)
/lib/ld-linux.so.2 (0xb7f8e000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7a74000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7a72000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7a5a000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7a55000)
so, when i try to run gdb with fltk-debug libs, it
segfaults instantly.
but what would i gain? heres the output of a backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a926c0 (LWP 28431)]
Fl_Group::draw_child (this=0x8076130, [EMAIL PROTECTED]) at Fl_Group.cxx:577
577 if (widget.visible() && widget.type() < FL_WINDOW &&
(gdb) bt
#0 Fl_Group::draw_child (this=0x8076130, [EMAIL PROTECTED]) at Fl_Group.cxx:577
#1 0xb7f45d50 in Fl_Group::draw_children (this=0x8076130) at Fl_Group.cxx:548
#2 0xb7f45e68 in Fl_Group::draw (this=0x8076130) at Fl_Group.cxx:563
#3 0xb7f45843 in Fl_Group::draw_child (this=0x80760a8, [EMAIL PROTECTED])
at Fl_Group.cxx:580
#4 0xb7f45d50 in Fl_Group::draw_children (this=0x80760a8) at Fl_Group.cxx:548
#5 0xb7f45e68 in Fl_Group::draw (this=0x80760a8) at Fl_Group.cxx:563
#6 0xb7f77607 in Fl_Window::draw (this=0x80760a8) at Fl_Window.cxx:109
#7 0xb7f3d8ec in Fl_Double_Window::flush (this=0x80760a8, eraseoverlay=0)
at Fl_Double_Window.cxx:410
#8 0xb7f3d937 in Fl_Double_Window::flush (this=0x80760a8)
at Fl_Double_Window.cxx:334
#9 0xb7f2eb7e in Fl::flush () at ../FL/x.H:126
#10 0xb7f2ed92 in Fl::wait (time_to_wait=1e+20) at Fl.cxx:371
#11 0xb7f2eed7 in Fl::run () at Fl.cxx:380
#12 0x080698f0 in main (argc=1, argv=0xbfa23fe4) at main.C:46
(gdb)
what other infos would i get if it was linked against the
debug libs? ty,
jan
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
