Re: Pretest?

["Jan Djärv" <jan.h.d@swipnet.se>]

Giorgos Keramidas skrev:
> On 2007-03-04 21:38, David Kastrup <dak@gnu.org> wrote:
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>>>
>>>>   FreeBSD 7.0-CURRENT #0: Tue Feb 27 01:25:46 EET 2007
>>>>
>>>> While I'm running the GTK+ version, however, I can crash Emacs in
>>>> emacs_blocked_free() by following the steps outlined below:
>>>>
>>>> * Run Emacs inside gdb:
>>>> * Run M-x gnus-agent-batch while my network connection is
>>>>   disabled, and let it time-out.  It prompts me for going into
>>>>   `off-line mode', to which I reply `yes'.
>>>> * The next time I input C-z Emacs crashes with a backtrace of:
>>> I can't seem to reproduce this on GNU/Linux (I don't have a FreeBSD
>>> box handy).  It's strange that gnus-agent batch has anything to do
>>> with it.  Have you been able to reproduce the C-z crash in any other
>>> circumstance?  (It is better to get a recipe not involving gnus, since
>>> that might depend on your newsgroup settings.)
>>>
>>> In any case, the backtrace indicates that the crash occurs deep in
>>> GTK/Glib.  If you look at what is occurring in the Emacs code, what
>>> we're doing is perfectly innocuous: gdk_pixbuf_new_from_xpm_data() is
>>> called on a static character array containing an XPM image.  So the
>>> bug is probably in GTK or Glib, not in Emacs.
>> Could not possibly have anything to do with the following?
>>
>> 2007-03-01  Kenichi Handa  <handa@m17n.org>
>>
>> 	* process.c (send_process_object): Check the process status and
>> 	signal an error if something is wrong.
> 
> I sort of doubt that, but I can test.
> 
> IIRC, Emacs 22.X had problems on FreeBSD with GTK+ a long time ago too.

As I recall, it was the threading issue that was the problem then.  Are there 
multiple threads running in Emacs at the time of the crash?  info threads in 
gdb will show you that.  A backtrace for each thread, if there are several, 
would be nice.

	Jan D.