swarm-support
[Top][All Lists]
Advanced

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

Re: "STATUS_ACCESS_VIOLATION" on Win 95


From: Barry McMullin
Subject: Re: "STATUS_ACCESS_VIOLATION" on Win 95
Date: Wed, 01 Apr 1998 20:45:36 +0100

Well folks, today brought a *little* further
progress. Here's the update:

o As far as I can make out, 

    Exception: STATUS_ACCESS_VIOLATION

  is simply the generic message from cygwin apps to
  indicate a memory protection violation - i.e. what is
  more commonly called a seg fault...

o I have no idea why I am experiencing additional
  problems with the b19.1 cywin dll release ... but I'd
  be interested whether anyone else encounters similar
  behaviour.  For the moment I'll just stick with the
  original b19 release.

o I've tracked the immediate problem with my (SCL) app
  to a call on [controlPanel doTkEvents] that I had
  failed to update to [actionCache doTkEvents], per the
  porting notes.  Ooops.

o My app now runs quite successfully - until I try to
  reload a new "world state"; then it crashes again
  with the old  STATUS_ACCESS_VIOLATION. Running in
  gdb I can capture a stack trace which I attach below
  in all its glory.

o The crash appears to arise from the scenario of
  dropping an object (userCellEditor) for which there
  is an existing Probe.  

o The interesting layers of the trace are (?) from #18
  down (deeper); at #18 the generic object drop method
  is invoked on an object with a probe on it; by #15 we
  see this resulting in a drop on the presumably
  corresponding SimpleProbeDisplay (at 0x49b42a0); this
  results in various complicated tcltk stuff, but
  culminates at level #1 with another nested invocation
  of drop on the *same* SimpleProbeDisplay (0x49b42a0).
  This definitely does not *seem* right, and it doesn't
  particularly surprise me that it causes a crash.

  This is all a hoary old swarm issue about correctly
  synchronising dopping of probes with dropping of the
  corresponding objects. Now it *may* be that my app is
  doing something weird that worked back on swarm 1.0.2
  or so, but becomes broken in 1.1; *or* it may be that
  there is something broken in 1.1. Since the crucial
  parts of the backtrace don't *seem* to involve my
  code, I'm a little suspicious that it may indicate 
  a lurking swarm bug...

  So: can anybody confirm to me that they have apps
  working in 1.1 where objects with probes get dropped?

o I have briefly scanned some of the relevant swarm code; I 
  notice that there is now some sort of mechanism to control
  whether probes get dropped immediately on request
  or via some kind of reaper queue; this gets
  switched via ControlPanel depending on the run state of
  the swarm (or something).  This may or may not be related
  to the problem I am experiencing, but, for the record,
  I believe we are in controlStateStopped when the drop 
  is attempted...

o In the meantime, I'll study the backtrace more
  carefully to try to make more sense of it...


Cheers,

Barry.


====================

Program received signal SIGSEGV, Segmentation fault.
0x49ea6f in objc_msg_lookup (receiver=0x49b7780, op=0x4b6454)
    at /wsrc/gnu-win32/src/gcc/objc/sendmsg.c:150
/wsrc/gnu-win32/src/gcc/objc/sendmsg.c:150: No such file or directory.
(gdb) bt
#0  0x49ea6f in objc_msg_lookup (receiver=0x49b7780, op=0x4b6454)
    at /wsrc/gnu-win32/src/gcc/objc/sendmsg.c:150
#1  0x417d5b in _i_SimpleProbeDisplay__drop (self=0x49b42a0, _cmd=0x4b74ec)
    at SimpleProbeDisplay.m:158
#2  0x41b934 in _i_CommonProbeDisplay__markForDrop (self=0x49b42a0,
    _cmd=0x4b7464) at CommonProbeDisplay.m:71
#3  0x450242 in _i_Object_s__perform_with_ (self=0x49b42a0, _cmd=0x4b8218,
    aSel=0x4b7464, anObject1=0x49b42f0) at DefObject.m:479
#4  0x424f78 in _i_ArchivedGeometryWidget___notifyTarget_ (self=0x49b42f0,
    _cmd=0x4b8220) at ArchivedGeometryWidget.m:93
#5  0x42501a in structure_proc (clientdata=0x49b42f0, eventptr=0x28b4254)
    at ArchivedGeometryWidget.m:101
#6  0x66335265 in Tk_HandleEvent ()
#7  0x6636fcea in Tk_DestroyWindow ()
#8  0x6632f078 in Tk_DestroyCmd ()
#9  0x66004044 in TclInvokeStringCommand ()
#10 0x6601f5fe in TclExecuteByteCode ()
#11 0x660049d1 in Tcl_EvalObj ()
#12 0x6600470f in Tcl_Eval ()
#13 0x45a41a in _i_TclInterp__eval_ (self=0x491b0b0, _cmd=0x4b86fc,
    fmt=0x426409 "destroy %s") at /localsrc/Swarm/tclobjc/TclInterp.m:279
#14 0x42674d in _i_Frame__drop (self=0x49b42f0, _cmd=0x4b646c) at Frame.m:99
#15 0x417dbf in _i_SimpleProbeDisplay__drop (self=0x49b42a0, _cmd=0x4b6088)
    at SimpleProbeDisplay.m:163
#16 0x41740b in notifyObjectDropped (anObject=0x49b1f28, realloc=0x0,
    pd=0x49b42a0) at ProbeDisplay.m:81
#17 0x44e70a in _i_Object_s__drop (self=0x49b1f28, _cmd=0x4b0c74)
    at DefObject.m:166
#18 0x403269 in _i_WorldManager__dropWorld (self=0x4973730, _cmd=0x4b1344)
    at WorldManager.m:273
#19 0x404d7e in _i_WorldManager__loadFrom_ (self=0x4973730, _cmd=0x4b143c,
    inFile=0x49ba110) at WorldManager.m:765
#20 0x405bbf in _i_WorldManager__loadFromFileNamed_ (self=0x4973730,
    _cmd=0x48f23c8, filename=0x49af540 "run1.stt") at WorldManager.m:833
#21 0x49dd35 in ffi_call_SYSV ()
#22 0x49dd1a in ffi_call (cif=0x28bca38,
    fn=0x405b2c <_i_WorldManager__loadFromFileNamed_>, rvalue=0x28bca54,
    avalue=0x28bc9f4) at /localsrc/libffi/src/x86/ffi.c:183
#23 0x43e556 in _i_MessageProbe__dynamicCallOn_ (self=0x4974b20,
    _cmd=0x4b6d10, target=0x4973730) at MessageProbe.m:436
#24 0x41986c in _i_MessageProbeWidget__dynamic (self=0x49825c0, _cmd=0x4b6c70)
    at MessageProbeWidget.m:172
#25 0x45c928 in tclObjc_msgSendToClientData (clientData=0x49825c0,
    interp=0x491c0b8, argc=2, argv=0x28bd1e4)
    at /localsrc/Swarm/tclobjc/tclObjc.m:520
#26 0x45d07e in tclObjc_msgSendToArgv1 (clientData=0x0, interp=0x491c0b8,
    argc=3, argv=0x28bd1e0) at /localsrc/Swarm/tclobjc/tclObjc.m:744
#27 0x66004044 in TclInvokeStringCommand ()
#28 0x6601f5fe in TclExecuteByteCode ()
#29 0x660049d1 in Tcl_EvalObj ()
#30 0x6603eaf5 in Tcl_UplevelObjCmd ()
#31 0x6601f5fe in TclExecuteByteCode ()
#32 0x660049d1 in Tcl_EvalObj ()
#33 0x6603f2e9 in TclObjInterpProc ()
#34 0x6601f5fe in TclExecuteByteCode ()
#35 0x660049d1 in Tcl_EvalObj ()
#36 0x6600470f in Tcl_Eval ()
#37 0x66005db0 in Tcl_GlobalEval ()
#38 0x6631cc7c in TkCopyAndGlobalEval ()
#39 0x6631ec18 in TkInvokeButton ()
#40 0x6631e220 in ButtonWidgetCmd ()
#41 0x66004044 in TclInvokeStringCommand ()
#42 0x6601f5fe in TclExecuteByteCode ()
#43 0x660049d1 in Tcl_EvalObj ()
#44 0x6603eadb in Tcl_UplevelObjCmd ()
#45 0x6601f5fe in TclExecuteByteCode ()
#46 0x660049d1 in Tcl_EvalObj ()
#47 0x6603f2e9 in TclObjInterpProc ()
#48 0x6601f5fe in TclExecuteByteCode ()
#49 0x660049d1 in Tcl_EvalObj ()
#50 0x6600470f in Tcl_Eval ()
#51 0x66005db0 in Tcl_GlobalEval ()
#52 0x66319737 in Tk_BindEvent ()
#53 0x6632edab in TkBindEventProc ()
#54 0x6633528c in Tk_HandleEvent ()
#55 0x663355a9 in WindowEventProc ()
#56 0x66037b06 in Tcl_ServiceEvent ()
#57 0x66037d7c in Tcl_DoOneEvent ()
#58 0x425be2 in tkobjc_doOneEventSync () at common.m:145
#59 0x41400f in _i_ControlPanel__setStateStopped (self=0x495cbb8,
    _cmd=0x4b5374) at ControlPanel.m:126
#60 0x413f45 in _i_ControlPanel__startInActivity_ (self=0x495cbb8,
    _cmd=0x4b5584, activityID=0x49abd18) at ControlPanel.m:95
#61 0x414710 in _i_GUISwarm__go (self=0x4948358, _cmd=0x4b0044)
    at GUISwarm.m:46
#62 0x40117a in main (argc=1, argv=0x28bfc6c) at main.m:21
#63 0x10006b59 in _size_of_stack_reserve__ ()
#64 0x10006b6c in _size_of_stack_reserve__ ()
#65 0x4ad97e in cygwin_crt0 ()

===============================



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================


reply via email to

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