[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 12 03:20:09 2003 
Subject:Re: Forwarded Re: INVALID ARRAY SUBSCRIPT leads to Pop core dump (PC linux + Windows 2000) 
From:lucb 
Volume-ID:1030112.01 

Wow! that was some sleuthing!

Congratulations!

Luc

On Tuesday, January 7, 2003, at 09:45 AM, Aaron Sloman wrote:

> [Forwarded message from non-member. Fixes the problem. I'll post
> a followup on what to do - Aaron]
>
> From: hebisch@math.uni.wroc.pl (Waldek Hebisch)
> Subject: Re: INVALID ARRAY SUBSCRIPT leads to Pop core dump (PC linux 
> + Windows 2000)
> Date: 7 Jan 2003 16:19:42 GMT
> Organization: Politechnika Wroclawska
>
> eas-lab@absamail.co.za wrote:
> : A.Sloman wrote:
> : > vars b = newarray([-1 5 -1 5]);
> : > b(6) =>
> : >
> : > ;;; MISHAP - INVALID ARRAY SUBSCRIPT
> : > ;;; INVOLVING:  6
> : > ;;; DOING    :  sys_exception_final sys_exception_handler
> : > ;;;     Segmentation fault (core dumped)
 
> : My redHat 6.2 on slow 486 only writes the first 2 lines if the 
> mishap.
>
> : > It looks as if the error test works, then _array_sub calls the 
 routine
> : > array_sub_error which succeeds in calling Sub_error, which invokes
> : > pop11's generic error handler, which starts printing out the error
> : > message, and fails half way through printing.
 
> :  I think:
> :   when there are no subscript errors, _array_sub exits via the
> : 	jmp	*_PD_EXECUTE(%eax)
> : ELSE it gets to:
> : 	subl	$4, %USP		;;; reveal the last index again
> : 	call	XC_LAB(weakref Sys$-Array$-Sub_error)
>         ^^^^
> jmp works OK
>
> : 	call	XC_LAB(setpop)		;;; in case the error returns
> : and crashes ?!
> <snip>
>
> I have checked that in most cases assembler jumps to poplog routines
> (instead of using call). So I changed (using gdb) the offending
> call to a jump (fortunately jump and call are of equal length and only
> opcode differs, so I just had to change single byte). After change
> poplog printed rest of error message and continued with no problem.
> So, my conclusion is that machine stack got corrupted -- call puts
> return adress on the machine stack and appearently error handling 
> routine
> has to examine the machine stack ...
>
>
> --
>                               Waldek Hebisch
> hebisch@math.uni.wroc.pl    or hebisch@hera.math.uni.wroc.pl
>
>