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?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
