On Sun, Nov 29, 2009 at 12:32:58PM -0500, Peter S Galbraith wrote: > [I have added Jens Thoms Toerring <j...@toerring.de>, the XForms > (upstream) maintainer to the CC list.]
Thanks, that's a good idea! > Colin Watson <cjwat...@debian.org> wrote: > > > [CC: libfor...@packages.debian.org] > > > > On Sat, Nov 28, 2009 at 11:53:21AM +0200, George Danchev wrote: > > > I can confirm that 3.1-10 crashes on startup on x86, but not on amd64. > > > I got the source in order to rebuilt with debugging symbols on x86, but > > > then > > > the app started just fine. My best bet is that something has changed > > > within the > > > underlying libraries, also looking at ltrace output: > > > > > > fl_set_object_lcol(0x9e2a500, 0, 0xbfbad678, 0x804bf28, 1) > > > = > > > 0x9e2a500 > > > fl_initial_wingeometry(8, 8, 220, 670, 0x37f0c7f) > > > = > > > 220 > > > fl_show_form(0x9e29a68, 0, 1, 0x8051237, 0x37f0c7f <unfinished ...> > > > --- SIGSEGV (Segmentation fault) --- > > > +++ killed by SIGSEGV +++ > > > > > > reveals that something has changed in the callback functions there. > > > I'm curious if rebuilding on x86 would make that crash go away. > > > > Thanks, and indeed I see similar symptoms here. Rebuilding does make it > > go away, but I think this is really a bug in libforms1 that needs to be > > fixed there. It will probably involve a kali rebuild at some point, but > > I'd like to hear from the libforms1 maintainer first. > > > > With kali built against libforms1 1.0-8 and a version of libforms1 > > 1.0.92sp1-5 built with debugging symbols and -O0, gdb's new reverse > > debugging support (yay!) quickly narrowed down the point where libforms1 > > jumps into space: > > > > (gdb) b fli_scale_form > > Function "fli_scale_form" not defined. > > Make breakpoint pending on future shared library load? (y or [n]) y > > Breakpoint 1 (fli_scale_form) pending. > > (gdb) r > > Starting program: /home/cjwatson/src/debian/kali/trunk/kali/kali > > > > Breakpoint 1, fli_scale_form (form=0x807c838, xsc=1, > > ysc=0.99178082191780825) at forms.c:515 > > 515 double neww = form->w_hr * xsc, > > (gdb) target record > > (gdb) c > > Continuing. > > Process record: failed to record execution log. > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x00000001 in ?? () > > (gdb) reverse-stepi > > 0x00c86968 in handle_object (obj=0x807d090, event=22, mx=0, my=0, key=0, > > xev=0x0, keep_ret=1) at objects.c:2426 > > 2426 obj->posthandle( obj, event, mx, my, key, xev ); > > > > So. On investigating the diff from libforms1 1.0-8 to 1.0.92sp1-5, I > > notice that a bunch of new members have been inserted into the FL_OBJECT > > structure, namely fl1, fr1, ft1, fb1, fl2, fr2, ft2, and fb2, all before > > posthandle. (There are also multiple changes after posthandle.) No > > wonder kali is breaking. > > > > Peter, doesn't this require libforms1 to have a new SONAME, or else to > > clean up its interface to be ABI-compatible with previous versions (at > > least by only ever appending members to structs)? > > I sounds like the current issue requires a new soname, but I'm guessing > that Jens didn't really mean to make it backwards incompatible with the > previous version. So we have a window to find the issue without a new > soname. > > What do you think Jens? That's right, the new version isn't meant to be backward compatible (several of the core data structures had to be augmented to remove bugs and improve a number of things). So, yes, a new SONAME is pro- bably in order (I wasn't aware of that being an issue until now - sorry, I haven't much practise yet with maintaining a library). I will try to figure out what I have to change to set a new SONAME and send Peter an email when I am done with it. > (And many thanks Colin, for all the work!) Also from me for pointing out this problem! Best regards, Jens -- \ Jens Thoms Toerring ________ j...@toerring.de \_______________________________ http://toerring.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org