emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest?


From: Giorgos Keramidas
Subject: Re: Pretest?
Date: Sun, 4 Mar 2007 22:47:07 +0200

On 2007-03-04 21:38, David Kastrup <address@hidden> wrote:
>Chong Yidong <address@hidden> writes:
>> Giorgos Keramidas <address@hidden> 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  <address@hidden>
>
>       * 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]