[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.
==================================
- Re: "STATUS_ACCESS_VIOLATION" on Win 95,
Barry McMullin <=