Re: Ediff frequently crashes emacs.

Re: Ediff frequently crashes emacs.

[Kim F. Storm]

Hi Peter -- have you seens any more crashes with at extra checks enabled?


BTW, I still wonder if the following observation could explain the
crashes -- perhaps depending on which version of libc is used
(supposing different versions may experience this problem/bug to a
lesser or bigger extent).

> Notably it crashed in various libc functions (setlocale, tzset)
> because they didn't seem to obey the malloc_hook and free_hook in a
> consistent manner, i.e. some data would be malloc'ed via the hook, but
> free'd without the hook--at least I saw the same piece of memory being
> malloc'ed twice by setlocale with no call to the free hook in-between.
>
> Perhaps, the crashes could be related to such errors in other libc
> functions, calling malloc/free without going through the hooks to
> properly use emacs_blocked_malloc and emacs_blocked_free.
>
> I think that could mess up the heap.
>
> If we could find other functions which did something like that,
> we could try to protect them with BLOCK_INPUT...  (sigh).


Also, can anyone explain why the call to free(malloc_state_ptr) crashes
when I enable XMALLOC_OVERRUN_CHECK ?

> BTW, when XMALLOC_OVERRUN_CHECK is defined, the call to
> free(malloc_state_ptr) in malloc_initialize_hook causes a
> consistent trap (in _int_free) when the dumped emacs was started.
> As a quick hack, I just disabled that specific free in this case.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Ediff frequently crashes emacs.

[Peter Seibel]

storm@cua.dk (Kim F. Storm) writes:

> Hi Peter -- have you seens any more crashes with at extra checks
> enabled?

Sadly I haven't had time to figure out how to build with the checks
enabled--as I mentioned last time the build fails with a segfault when
I set that flag to 1. It has crashed a few times since then--seemingly
in different places each time. Sorry I can't be more help but I'm
presently busy with other stuff such as trying to finish (writing) a
book. When I have a bit more time I'll try to investigate more
thoroughly.

> BTW, I still wonder if the following observation could explain the
> crashes -- perhaps depending on which version of libc is used
> (supposing different versions may experience this problem/bug to a
> lesser or bigger extent).

Is there any more information about my system I can send you that will
help identify what's different about my setup?

-Peter

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Re: Ediff frequently crashes emacs.

[Richard Stallman]

    > Notably it crashed in various libc functions (setlocale, tzset)
    > because they didn't seem to obey the malloc_hook and free_hook in a
    > consistent manner, i.e. some data would be malloc'ed via the hook, but
    > free'd without the hook--at least I saw the same piece of memory being
    > malloc'ed twice by setlocale with no call to the free hook in-between.

Can you find one single library function that really does do this,
and figure out why it does?

    Also, can anyone explain why the call to free(malloc_state_ptr) crashes
    when I enable XMALLOC_OVERRUN_CHECK ?

I don't know why, but the amount of leakage in never freeing this
is insignificant, so I'd say just delete that call to `free'.

Re: Ediff frequently crashes emacs.

[Richard Stallman]

    Sadly I haven't had time to figure out how to build with the checks
    enabled--as I mentioned last time the build fails with a segfault when
    I set that flag to 1.

Please try to debug that crash.  Since it is reproducible, debugging it
should be straightforward even though it may take work.  Once the new
checking features are working, they will probably find us the other
bugs that we can't find in another way.

In fact, I think we should turn on the new checking features by default
so that (1) people will debug them, and (2) people will find the other bugs.

Re: Ediff frequently crashes emacs.

[Kim F. Storm]

Peter Seibel <peter@javamonkey.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> Hi Peter -- have you seens any more crashes with at extra checks
>> enabled?
>
> Sadly I haven't had time to figure out how to build with the checks
> enabled--as I mentioned last time the build fails with a segfault when
> I set that flag to 1.

Could you try running

gdb temacs
r -batch -l loadup dump

and then tell me where it traps

bt
xbacktrace


> It has crashed a few times since then--seemingly
> in different places each time. Sorry I can't be more help but I'm
> presently busy with other stuff such as trying to finish (writing) a
> book. When I have a bit more time I'll try to investigate more
> thoroughly.


Could you at least post the backtraces (bt, xbacktrace) whenever it
crashes.  Thanks.

Re: Ediff frequently crashes emacs.

[Peter Seibel]

no-spam@cua.dk (Kim F. Storm) writes:

> Peter Seibel <peter@javamonkey.com> writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> Hi Peter -- have you seens any more crashes with at extra checks
>>> enabled?
>>
>> Sadly I haven't had time to figure out how to build with the checks
>> enabled--as I mentioned last time the build fails with a segfault when
>> I set that flag to 1.
>
> Could you try running
>
> gdb temacs
> r -batch -l loadup dump

You mean with an emacs built with the flag 0 or is this something I
can run after building some subset that you think will actually build.

> and then tell me where it traps
>
> bt
> xbacktrace
>
>
>> It has crashed a few times since then--seemingly in different
>> places each time. Sorry I can't be more help but I'm presently busy
>> with other stuff such as trying to finish (writing) a book. When I
>> have a bit more time I'll try to investigate more thoroughly.
>
>
> Could you at least post the backtraces (bt, xbacktrace) whenever it
> crashes.  Thanks.

Sure.

-Peter

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Re: Ediff frequently crashes emacs.

[Kim F. Storm]

Peter Seibel <peter@javamonkey.com> writes:

>>> Sadly I haven't had time to figure out how to build with the checks
>>> enabled--as I mentioned last time the build fails with a segfault when
>>> I set that flag to 1.
>>
>> Could you try running
>>
>> gdb temacs
>> r -batch -l loadup dump
>
> You mean with an emacs built with the flag 0 or is this something I
> can run after building some subset that you think will actually build.

No, I meant with the flag 1.

You said it segfault during build -- so I assumed that it was temacs
(the undumped emacs) that segfaulted -- so I suggested you debugged
where temacs trapped.  That would help me to figure out what the
problem might be.

>
>> and then tell me where it traps
>>
>> bt
>> xbacktrace
>>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Ediff frequently crashes emacs.

[Peter Seibel]

no-spam@cua.dk (Kim F. Storm) writes:

> Could you at least post the backtraces (bt, xbacktrace) whenever it
> crashes. Thanks.

Okay, here's another one, again while using ediff.

-Peter

(gdb) run
Starting program: /usr2/cvs/emacs/src/emacs -geometry 80x40+0+0

Program received signal SIGSEGV, Segmentation fault.
0x420824ed in bcopy () from /lib/i686/libc.so.6
(gdb) backtrace
#0  0x420824ed in bcopy () from /lib/i686/libc.so.6
#1  0x0804ff1f in safe_bcopy (from=0x89b3268 "\250b\214\t", to=0x9a17cf0 "", 
    size=160195232) at dispnew.c:484
#2  0x08125694 in compact_small_strings () at alloc.c:2038
#3  0x0812896b in gc_sweep () at alloc.c:5372
#4  0x08127a05 in Fgarbage_collect () at alloc.c:4699
#5  0x080e5a19 in read_char (commandflag=1, nmaps=2, maps=0xbffff250, 
    prev_event=137284881, used_mouse_menu=0xbffff288) at keyboard.c:2773
#6  0x080ec2b4 in read_key_sequence (keybuf=0xbffff3b0, bufsize=30, 
    prompt=137284881, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8788
#7  0x080e392b in command_loop_1 () at keyboard.c:1528
#8  0x081390a2 in internal_condition_case (bfun=0x80e360c <command_loop_1>, 
    handlers=137345857, hfun=0x80e31b0 <cmd_error>) at eval.c:1382
#9  0x080e3496 in command_loop_2 () at keyboard.c:1309
#10 0x08138c53 in internal_catch (tag=137339865, 
    func=0x80e3478 <command_loop_2>, arg=137284881) at eval.c:1143
#11 0x080e3425 in command_loop () at keyboard.c:1288
#12 0x080e2f6f in recursive_edit_1 () at keyboard.c:981
#13 0x080e3097 in Frecursive_edit () at keyboard.c:1042
#14 0x080e1f37 in main (argc=3, argv=0xbffff984) at emacs.c:1742
#15 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) xbacktrace
(gdb) 



-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Re: Ediff frequently crashes emacs.

[Richard Stallman]

Could you try enabling these definitions in lisp.h and recompiling,
and see if it helps you find the bug?

(If it crashes for any other reason, we want to debug that too.)


#if 0
/* Define this temporarily to hunt a bug.  If defined, the size of
   strings is redundantly recorded in sdata structures so that it can
   be compared to the sizes recorded in Lisp strings.  */

#define GC_CHECK_STRING_BYTES 1

/* Define this to check for short string overrun.  */

#define GC_CHECK_STRING_OVERRUN 1

/* Define this to check the string free list.  */

#define GC_CHECK_STRING_FREE_LIST 1

/* Define this to check for malloc buffer overrun.  */

#define XMALLOC_OVERRUN_CHECK 1

/* Define this to check for errors in cons list.  */
/* #define GC_CHECK_CONS_LIST 1 */

#endif /* 0 */

Re: Ediff frequently crashes emacs.

[Peter Seibel]

Richard Stallman <rms@gnu.org> writes:

> Could you try enabling these definitions in lisp.h and recompiling,
> and see if it helps you find the bug?

Yes. Running as I write. I'll let you know the next time it crashes.
This is progress however: a couple weeks ago I couldn't even build
with these checks turned on.

-Peter

>
> (If it crashes for any other reason, we want to debug that too.)
>
>
> #if 0
> /* Define this temporarily to hunt a bug.  If defined, the size of
>    strings is redundantly recorded in sdata structures so that it can
>    be compared to the sizes recorded in Lisp strings.  */
>
> #define GC_CHECK_STRING_BYTES 1
>
> /* Define this to check for short string overrun.  */
>
> #define GC_CHECK_STRING_OVERRUN 1
>
> /* Define this to check the string free list.  */
>
> #define GC_CHECK_STRING_FREE_LIST 1
>
> /* Define this to check for malloc buffer overrun.  */
>
> #define XMALLOC_OVERRUN_CHECK 1
>
> /* Define this to check for errors in cons list.  */
> /* #define GC_CHECK_CONS_LIST 1 */
>
> #endif /* 0 */
>

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Re: Ediff frequently crashes emacs.

[Richard Stallman]

    Yes. Running as I write. I'll let you know the next time it crashes.
    This is progress however: a couple weeks ago I couldn't even build
    with these checks turned on.

That is very good news.  Maybe we should turn these tests on by
default.