help-smalltalk
[Top][All Lists]
Advanced

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

[Help-smalltalk] SIGSEGV in _gst_async_file_polling() in events.c


From: Carlos Moran
Subject: [Help-smalltalk] SIGSEGV in _gst_async_file_polling() in events.c
Date: Wed, 5 Feb 2003 11:55:20 -0800 (PST)

I loaded Blox and the WebServer in an image with:
    cp /usr/local/share/smalltalk/gst.im web.im
    gst -I web.im -qK Load.st -a Blox WebServer
Browser

Then I started both Blox and a WebServer:
gst -I ~/web.im -q
GNU Smalltalk ready
st> NetClients WikiWorks WebServer
publishMyFileSystem.!
st> BLOX BLOXBrowser BrowserMain new initialize!
st> 

Then I downloaded two files, and gst aborted with this
stack trace dump:
stdin:2: Aborted
TCPSocketImpl(AbstractSocketImpl)>>#ensureReadable
[] in Socket>>#newReadBuffer:
ReadBuffer>>#atEnd
Socket>>#peek
Socket>>#atEnd
CrLfStream>>#atEnd
CrLfStream(Stream)>>#upTo:
WebRequest>>#extractAction
WebRequest>>#getRequest
WebRequest>>#initConnection:
WebRequest class>>#for:
WebSession>>#next
[] in NetSession>>#run
BlockClosure>>#on:do:
WebSession(NetSession)>>#run
[] in NetThread>>#newProcess
[] in Process>>#onBlock:at:suspend:
BlockClosure>>#on:do:
[] in Process>>#onBlock:at:suspend:
BlockContext class>>#fromClosure:parent:
Aborted

I ran it again with -c, downloaded another pair of
files, and gst aborted again, producing a core dump.
The C stack trace dump is as follows:
#0  0x4004a361 in __kill () at __kill:-1
#1  0x4004a038 in raise (sig=6) at
../sysdeps/posix/raise.c:27
#2  0x4004b88b in abort () at
../sysdeps/generic/abort.c:88
#3  0x0806071e in oldspace_sigsegv_handler
(fault_address=0x8, serious=0)
    at oop.c:851
#4  0x08089090 in sigsegv_handler (sig=11, sc=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43,
__esh = 0, ds = 43, __dsh = 0, edi = 0, esi = 0, ebp =
3221216620, esp = 3221216596, ebx = 140505832, edx =
0, ecx = 1, eax = 0, trapno = 14, err = 6, eip =
134767541, cs = 35, __csh = 0, eflags = 66050,
esp_at_signal = 3221216596, ss = 43, __ssh = 0,
fpstate = 0xbfffdad8, oldmask = 0, cr2 = 8}) at
handler.c:150
#5  <signal handler called>
#6  0x080863b5 in _gst_async_file_polling (fd=5,
cond=0, 
    semaphoreOOP=0x40324550) at events.c:305
#7  0x0807bbe0 in VMpr_FileDescriptor_fileOp (id=0,
numArgs=3)
    at prims.def:5071
#8  0x08084c20 in _gst_execute_primitive_operation
(primitive=210, numArgs=3)
    at interp.c:2446
#9  0x0807e517 in _gst_send_message_internal
(sendSelector=0x402a2e38, 
    sendArgs=3, receiver=0x40321e98,
method_class=0x40303ba0)
    at interp-bc.inl:301
#10 0x0807fe87 in _gst_interpret
(processOOP=0x402a5390) at interp-bc.inl:1831
#11 0x08084533 in _gst_nvmsg_send
(receiver=0x4029b800, 
    sendSelector=0x402a5260, args=0x0, sendArgs=0) at
interp.c:2047
#12 0x08056aef in _gst_execute_statements
(temporaries=0x0, 
    statements=0x85e3104, quiet=true) at comp.c:696
#13 0x08053693 in _gst_yyparse () at gst-parse.y:140
#14 0x08055638 in _gst_parse_stream () at lex.c:1097
#15 0x08052a8d in process_stdin () at lib.c:783
#16 0x08052598 in gst_top_level_loop () at lib.c:591
#17 0x08052188 in main (argc=5, argv=0xbffff994) at
main.c:49
#18 0x4003917d in __libc_start_main (main=0x8052160
<main>, argc=5, 
    ubp_av=0xbffff994, init=0x8051788 <_init>,
fini=0x80894a0 <_fini>, 
    rtld_fini=0x4000a534 <_dl_fini>,
stack_end=0xbffff98c)
    at ../sysdeps/generic/libc-start.c:129

The problem seems to be that the polling_queue list in
_gst_async_file_polling is corrupted in line 231 when
NULL is assigned to tail, instead of a pointer to the
last remaining element. This null pointer causes a
segmentation violation fault in line 305, because tail
is null and head is not null.

The corruption happens here:
 ...
             /* Pass over the current node */
              *pprev = node->next;
              if (tail == node)
                tail = NULL;   <=HERE

              xfree (node); 
...

The segmentation fault happens here:
...
  if (result == 0)
    {
      if (!head)
        tail = head = new;
      else
        tail = tail->next = new; <=HERE
...

I propose to replace the tail pointer with a pointer
to the next element pointer in the tail. In other
words, a pointer to the location where you have to
write a pointer to a new tail. This pointer can point
to head initially, and then point to the "next" field
of the last element in the list.

The attached file is the modified version of
libgst/events.c.

Carlos MorĂ¡n



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Attachment: events.c
Description: events.c


reply via email to

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