[Debian GNUstep maintainers] Bug#568049: gnumail.app: GNUMail systematically segfaults at startup

[Yavor Doganov]

On Tue, Feb 02, 2010 at 10:25:00AM -0500, Ian D. Leroux wrote:
> The error also occurs when I run Preview or AddressManager or Cynthiune.

Disturbing...  At least it's a proff that's not a bug in gnumail.app.

> The backtraces are different in each case, but the last 14 stack frames,
> from
> #13 -[NSMenu setMenuChangedMessagesEnabled:])
> to
> #0 object_is_instance (object=0x7)
> are always the same.

The implementation of this method hasn't changed for a long time, I
think.  It might be an incompatible change in gnustep-base/1.19.3
(among the many enumerated already), but we'll have to investigate.

> The output and backtrace from
> $ gdb --args GNUMail --GNU-Debug=dflt
> follow.

Thanks.

> Note that the initial errors about X not making the window visible
> may be unrelated

Yes, that's normal and expected.

> #19 0x00007ffff7ad5123 in ?? () from /usr/lib/libGNUMail.so.1

How come that gnumail.app-dbg is installed but this frame is
meaningless?  Anyway, it's not very important as we already know
GNUMail is not the culprit.

So, to figure out where the problem lies, could you do the following
steps, please (performing the next step is not needed if the prior
step leads to successful results):

1.  Do you start gdnc from your .bashrc/.xsession/etc?  As you said
    you've never used GNUstep apps before, I doubt it.  GDNC should be
    started automatically by the gnustep-base library, but the
    implementation (via NSTask) is fragile, and upstream considers it
    NOTABUG (i.e. they say that every GNUstep user should launch gdnc
    in her init scripts explicitly).
    Does the problem occur if you start gdnc in the session?
    If it disappears, there's a bug in gnustep-base; and I'll send you
    a test program to confirm this.

2.  If 1) fails, I'll send you another test program to confirm that
    this is not the locking race condition that we've been bitten
    before.  It was supposed to be fixed, but who knows.  If this
    test program fails, it means that the original bug is still not
    reliably fixed on 64-bit archs.

3) If 1) and 2) fail, that would probably mean the problem is not in
    -base.  Perhaps it's asking too much, but installing -gui and
    -back packages from experimental (+ rebuilding, let's say,
    preview.app), will fortunately confirm that the problem is fixed
    in newer versions of -gui (but this is unlikely, as the error is
    much lower level AFAIU).


P.S.: Anyone from the team having access to a 64-bit arch and
      experiencing similar troubles?