[Cuis-dev] Another puzzle

[Jan Vraný]

On Fri, 2024-06-14 at 08:59 +0000, Jaromir Matas via Cuis-dev wrote:
> 
> On 14-Jun-24 1:12:35 AM, "Andres Valloud via Cuis-dev" 
> <cuis-dev at lists.cuis.st> wrote:
> 
> > Hello, continuing with the puzzling behavior, here's one from a
> > book signature I got back in the year 1999 or so.
> > 
> > a := Array new: 2.
> > a at: 1 put: #perform:withArguments:.
> > a at: 2 put: a.
> > a perform: (a at: 1) withArguments: (a at: 2)
> 
> wicked :)  My guess is because #perform:withArguments: is a primitive
> the infinite loop happens inside the VM when the VM tries to evaluate
> the arguments. 

The VM just runs out of stack. Let's have a look in GDB:

...
Thread 1 "pharo" received signal SIGSEGV, Segmentation fault.
0x00005555555cc1cf in primitivePerformWithArgs ()
    at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-cointerp.c:37631
37631	{   DECL_MAYBE_SQ_GLOBAL_STRUCT

What the VM was doing when it crashed? 

(gdb) bt 5
#0  0x00005555555cc1cf in primitivePerformWithArgs ()
    at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-cointerp.c:37631
#1  0x00005555555ca33b in slowPrimitiveResponse ()
    at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-cointerp.c:24422
#2  executeNewMethod () at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-
cointerp.c:19557
#3  0x00005555555cc318 in primitivePerformWithArgs ()
    at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-cointerp.c:37735
#4  0x00005555555ca33b in slowPrimitiveResponse ()
    at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-cointerp.c:24422
#5  executeNewMethod () at /redacted/Pharo/pharo-vm/spur64src/vm/gcc3x-
cointerp.c:19557
(More stack frames follow...)

Let's see what code exactly was executed when it crashed? 

Dump of assembler code from 0x5555555cc1c5 to 0x5555555cc1d9:
   0x00005555555cc1c5 <primitivePerformWithArgs+37>:	jne   
0x5555555cc330 <primitivePerformWithArgs+400>
   0x00005555555cc1cb <primitivePerformWithArgs+43>:	push   %rbp
   0x00005555555cc1cc <primitivePerformWithArgs+44>:	mov   
%rsp,%rbp
=> 0x00005555555cc1cf <primitivePerformWithArgs+47>:	push   %r14
   0x00005555555cc1d1 <primitivePerformWithArgs+49>:	push   %r13
   0x00005555555cc1d3 <primitivePerformWithArgs+51>:	push   %r12
   0x00005555555cc1d5 <primitivePerformWithArgs+53>:	push   %rbx
   0x00005555555cc1d6 <primitivePerformWithArgs+54>:	movzbl
0x7(%rcx),%r12d
End of assembler dump.

Pushing a value onto a stack, what's the value of stack pointer: 

(gdb) p $rsp
$1 = (void *) 0x7fffff7ff000

That's a bit funny value...

(gdb) info proc mapping $rsp
Mapped address space for 0x7fffff7ff000:

          Start Addr           End Addr       Size     Offset  Perms 
objfile
      0x7fffff7ff000     0x7ffffffff000   0x800000        0x0  rw-p  
[stack]

So, stack pointer points just to the bottom of the stack segment.
Executing push instruction would store value to unmapped address,
causing the crash.

Fixing this issue is left as an excercise for the reader :-) 

Best, Jan


> I have no idea whether it is even possible to interrupt 
> such a loop by `Alt+.` escape sequence. I'm looking forward to what 
> others have to say. Thanks! Jaromir
> 
> 
> > 
> > 
> > Currently this expression crashes the VM.
> > 
> > Eem... the person that signed that in my book is well aware of this
> > example :p.
> > 
> > Even if this doesn't crash, you should still be able to break out
> > of it by invoking the debugger.  An infinite loop that you can't
> > interrupt is unacceptable behavior too.
> > 
> > Andres.
> > -- Cuis-dev mailing list
> > Cuis-dev at lists.cuis.st
> > https://lists.cuis.st/mailman/listinfo/cuis-dev
> > 
> >