On Tue, 14 Aug 2001, robin wrote:

>
> I'm also aware that without enough information to reproduce a bug, in 99% of
> cases there's little that can be done - from a scientific perspective it
> might even be said not to exist.  In future, I'll make sure to include it.
>

Select from the browser, PseudoContext, then go through the menu for
'sample instance' CRASH.

Recursive not understood error encountered


1090900340 CodeHolder>makeSampleInstance
1090900248 [] in MenuItemMorph>invokeWithEvent:
1090899972 BlockContext>ensure:
1090899880 Cursor>showWhile:
1090877840 MenuItemMorph>invokeWithEvent:
1090877732 MenuItemMorph>mouseUp:
1090877640 MenuItemMorph>handleMouseUp:
1090877456 MouseButtonEvent>sentTo:
1090877364 Morph>handleEvent:
...

This bug also applies to attempting to make sample instances with other
classes. You can run an automated test for this and see where else it
breaks.

--

Open up a bunch of sockets, stay connected to them, then save your image,
then try to restore from the saved image. You'll almost alwyas get *this*
traceback; this is the second time out of about 4 attempts that I've hit
this, and it makes my image unusable. My implementation is to construct a
seperate process to read&write from the socket. The image crashes after a
second when this process runs and causes the primitive to segfault:

crosby at dragonlight:~/squeak/squeak.mud-3.1$ /usr/local/packages/squeak-3.1/bin/squeak

Segmentation fault

1090757868 Socket>destroy
1088785580 MuckSocket>waitForData
1088785460 MuckSocket>networkGetSingleLine
1088674572 [] in MuckPlayerConnection>networkReaderLoop
1088674848 BlockContext>on:do:
1088674480 BlockContext>ifError:
1088674388 MuckPlayerConnection>networkReaderLoop
1088673964 [] in MuckPlayerConnection>initialize:
1088674056 [] in BlockContext>newProcess

--

My workaround is to replace *THIS* function so that it always fails.

static int socketValid(SocketPtr s) {
  interpreterProxy->success(false);
  return false;

	/* ORIGIONAL BODY */
  if ((s != 0) && (s->privateSocketPtr != 0) && (s->sessionID ==  thisNetSession))
    return true;
  interpreterProxy->success(false);
  return false;
}

I then run under this version of squeak to recover my image and code; then
back under my normal squeak binary to continue testing.

My suspician was that 's' isn't being cleaned up upon image reload, and
dereferencing it here was the cause of the segfault.

--

Then, there are cases where you overload it with packets, and process
switches; I've crashed it 3/4 times, and each in a different way.


Scott