On 2008-11-13, MacArthur, Ian (SELEX GALILEO, UK) <[EMAIL PROTECTED]> wrote:
>
>
>
>> what other infos would i get if it was linked against the
>> debug libs? ty,
>
> With the debug lib, it makes it easier to (via symbol names) query the
> value of variables and so forth at the break point, e.g. you can do
>
>> p widget
>
> (P == print value of)
>
> And it will print the current value of "widget", so you can look for
> NULL pointers or incorrect variables an etc.
>
> However, I see that you are linking to fltk dynamically; To investigate
> this problem, I would first switch to static linking, at least for fltk
> and the other small libs (portmidi and porttime I always static link,
> they are so tiny and it can save a lot of hassle) as this removes any
> ambiguity about which version is being loaded and so forth, and makes it
> much easier to determine at link time if there are any missing symbols
> or not.
>
> Once you have the static linked version playing nice, then try the
> dynamic linked version again...
>
ok, i have a statically linked version now with all debug
symbols and no missing symbols :)
$ ldd prodatum
linux-gate.so.1 => (0xb7f22000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e26000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e0e000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7d4a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7c57000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c32000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c27000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ad8000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7ad6000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7abd000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ab9000)
/lib/ld-linux.so.2 (0xb7f23000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7ab6000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7ab1000)
i just built fltk again (statically this time) and put
libfltk.a in my projects folder, added -L.. and -lX11 and
some others and here we go. same for portmidi.
gui shows up as it should and then segv, so everything is
as it should be, yeah up to the segv of course :)
now a backtrace gives me one more function call:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b026c0 (LWP 5133)]
0x0806c5ee in Fl_Widget::visible (this=0x3) at ../FL/Fl_Widget.H:163
163 int visible() const {return !(flags_&INVISIBLE);}
(gdb) bt
#0 0x0806c5ee in Fl_Widget::visible (this=0x3) at ../FL/Fl_Widget.H:163
#1 0x080738ce in Fl_Group::draw_child (this=0x80bf3c8, [EMAIL PROTECTED])
at Fl_Group.cxx:577
#2 0x08073b57 in Fl_Group::draw_children (this=0x80bf3c8) at Fl_Group.cxx:548
#3 0x08073c0f in Fl_Group::draw (this=0x80bf3c8) at Fl_Group.cxx:563
#4 0x08073962 in Fl_Group::draw_child (this=0x80bf340, [EMAIL PROTECTED])
at Fl_Group.cxx:580
#5 0x08073b57 in Fl_Group::draw_children (this=0x80bf340) at Fl_Group.cxx:548
#6 0x08073c0f in Fl_Group::draw (this=0x80bf340) at Fl_Group.cxx:563
#7 0x08089ebf in Fl_Window::draw (this=0x80bf340) at Fl_Window.cxx:109
#8 0x0807349a in Fl_Double_Window::flush (this=0x80bf340, eraseoverlay=0)
at Fl_Double_Window.cxx:410
#9 0x080735a3 in Fl_Double_Window::flush (this=0x80bf340)
at Fl_Double_Window.cxx:334
#10 0x0806c704 in Fl_X::flush (this=0x80d5578) at ../FL/x.H:126
#11 0x0806c184 in Fl::flush () at Fl.cxx:477
#12 0x0806c425 in Fl::wait (time_to_wait=1e+20) at Fl.cxx:371
#13 0x0806c4b6 in Fl::run () at Fl.cxx:380
#14 0x08069f90 in main (argc=1, argv=0xbfd73334) at main.C:46
(gdb) kill
the #0 line wasnt there before.
so it segfaults while its calling a method
int visible() const {return !(flags_&INVISIBLE);}
of a widget that has adress 0x3 which again is not
accessable memory. now, my question would be:
1: why isnt it accessable?
2: which widget is it?
any hints? ty
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
