bug#57751: 29.0.50; crash in GC

[Gerd Möllmann]

Sam Steingold <sds@gnu.org> writes:

> I _think_ that Tramp does something with a BAD FD and corrupts the
> memory (see my previous message: tramp appears to be broken recently).

Hm.  There have been a number of Tramp commits/fixes recently, so it
could be that something broke.  I'd report that as a bug, maybe after
updating to the ltest master.

I can't exclude that as a possibility, of course, but I think it's
unlikely that using Tramp can lead to a corruption of the C heap
somehow.

>
>> - Does it also crash when you run emacs on a terminal (-nw)?  If not, it
>>   could be a hint that the cuöprit is in the NS GUI code.
>
> (lldb) run -nw
> There is a running process, kill it and restart?: [Y/n] y
> Process 18589 exited with status = 9 (0x00000009) 
> Process 53208 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
> emacs(53208,0x101748600) malloc: nano zone abandoned due to inability to 
> preallocate reserved vm space.
> Process 53208 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
>     frame #0: 0x00007ff81575bec6 libsystem_kernel.dylib`__ioctl + 10
> libsystem_kernel.dylib`__ioctl:
> ->  0x7ff81575bec6 <+10>: jae    0x7ff81575bed0            ; <+20>
>     0x7ff81575bec8 <+12>: movq   %rax, %rdi
>     0x7ff81575becb <+15>: jmp    0x7ff815759db9            ; cerror
>     0x7ff81575bed0 <+20>: retq   
> Target 0: (emacs) stopped.

Oh, another thing I forgot to mention: LLDB requires a magic spell for
running terminal apps, instead of "run":

process launch --tty -- -nw

\o/ :-).

>> - Could you please see if it crashes consistently in different runs?
>>   What I mean is that is crashes in the same function with the same
>>   backtrace and the same pointer value of the symbol in frame#0?  I
>>   guess I would quit LLDB between between runs, for no good reason
>>   :-), just to make sure it's reproducible that way.
>
> I restarted lldb and run Emacs.
> This time I let it finish restoring desktop _completely_ before moving
> the frame - it did __NOT__ crash. I moved the frame around, no crash.

Ok.  So we have a workaround, at least.

> Then I quit it and restarted and moved the frame while it was in the
> process of re-creating *vc-dir* buffers.

Ok.  Moving means grabbing the titlebar?  I'm asking because of the
"part = scroll_bar_nowhere" in the event.  I wonder if one has to grab
the frame at a certain location?  And, are you using scroll bars or are
they off?

> Process 53726 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x7ff8c11d2f50)
>     frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) 
> at alloc.c:4020:14
>    4017 {
>    4018   return pdumper_object_p (s)
>    4019     ? pdumper_marked_p (s)
> -> 4020     : s->u.s.gcmarkbit;
>    4021 }
> (lldb) p *event
> (buffered_input_event) $0 = {
>   kind = MOVE_FRAME_EVENT
>   ie = {
>     kind = MOVE_FRAME_EVENT
>
> looks consistent with the previous crash.

That's nice!  I feel we're on the trail of the killer.  I have no idea
what's behind this, but maybe I can get something that I can reproduce
now.

>
>> - I think you mentioned that the crashes started not so long ago?  Do
>>   you perhaps know a commit which is still "good"?  Or maybe a time,
>>   like 4 weeks ago, or so?  We would need a good commit for git bisect
>>   anyway.
>
> I am "pretty sure" that 2 weeks ago it was good.

Ok.  

I think I'll try next to reproduce this desktop loading/moving frame
crash here.  When I get something, I'll bisect, and then let's see
further.  I'll report back when I have something.

>
>> (If I'm trying the be too "helpful", please just tekk ne.  I Know that
>> I'm sometimes doing that.  No problem.)
>
> You are very helpful, and I appreciate your attention!
>
> Thank you very much!

Thanks, good to know!  Helps.