[vwnc] debugging RuntimeQuietEmergencyNotifier
Locked
[vwnc] debugging RuntimeQuietEmergencyNotifier
 
|
In VW 7.4.1 we used RuntimeQuietEmergencyNotifier and it generated nice error logs. In 7.6 there seems to be an error during the notification that is proving hard to track. In a development image I can generate the error and it opens a debugger as expected. But in a 7.6 runtimePackager built image we now have a 100% cpu usage, no error log and none of the usual interrupts from control-Y or shift-control-Y (emergency evaluator) work. Rebuilding with all of the subclasses of RuntimeErrorNotifier or even just ErrorNotifier - all have the same symptom. This leads me to suspect something wrong in Notification.. Or the other possibility - the runtime packager stripped a method it should not. Looks to me like I need to rebuild with log statements added into the Notifier class methods.. Other Ideas on how to narrow this down more would be most welcome. Thanks
Will Loew-Blosser| Grain I/T| Cargill, Inc.
Confidentiality Note: This message is intended only for the named recipient and may contain confidential, proprietary or legally privileged information. Unauthorized individuals or entities are not permitted access to this information. Any dissemination, distribution, or copying of this information is strictly prohibited.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] debugging RuntimeQuietEmergencyNotifier
|
|
Two and a half suggestions
- execute "Notifier current: ErrorNotifier" It's possible that in 7.6 the ErrorNotifier logs are adequate for what you want. - Or, do the same, but with RuntimeQuietEmergencyNotifier. Either will force the development image to log the error rather than producing a debugger, and might make it easier to break into the notification. However, it might be necessary to do some other preparation on the Runtime Packager one. I tried this myself, and you had to also set the errorFilename: and imageDumperClass:, and even then it was trying to dump to '' and failing out. And doing it more than once in the same image, some global state can linger such that it thinks you have a recursive attempt to dump when you don't. Setting "RuntimeErrorNotifier debugNotifierMode: true" before causing the walkback might also be helpful. - run using the debug version of the vm and the -o10s command line option redirected to a file. This will produce an absolutely gigantic log of all (or at least most) message sends. Examining this is painful, but if you break execution and examine it, with any luck you find yourself in a tight loop at the end of the file that would be informative as to what's going on. At 01:55 PM 8/7/2008, [hidden email] wrote: Content-class: urn:content-classes:messageIn VW 7.4.1 we used RuntimeQuietEmergencyNotifier and it generated nice error logs. In 7.6 there seems to be an error during the notification that is proving hard to track. In a development image I can generate the error and it opens a debugger as expected. But in a 7.6 runtimePackager built image we now have a 100% cpu usage, no error log and none of the usual interrupts from control-Y or shift-control-Y (emergency evaluator) work. Rebuilding with all of the subclasses of RuntimeErrorNotifier or even just ErrorNotifier - all have the same symptom. This leads me to suspect something wrong in Notification.. Or the other possibility - the runtime packager stripped a method it should not. Looks to me like I need to rebuild with log statements added into the Notifier class methods.. Other Ideas on how to narrow this down more would be most welcome. Thanks Will Will Loew-Blosser| Grain I/T| Cargill, Inc. 15407 McGinty Rd West, MS #64 | Wayzata, MN 55391 952.742.7138 | [hidden email] Confidentiality Note: This message is intended only for the named recipient and may contain confidential, proprietary or legally privileged information. Unauthorized individuals or entities are not permitted access to this information. Any dissemination, distribution, or copying of this information is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete this message and any attachments. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] debugging RuntimeQuietEmergencyNotifier
|
|
In reply to this post by Will_Loew-Blosser
thanks
Alan,
I'm
running with the debug vm and the -o10s but can you give an example of the
command line redirect syntax to a file?
I
remember seeing another post about some of the undocumented command line options
but just can't lay my hands on it.
(Where is it?)
Using
the -o10s option, output goes to a
terminal window.. and it is a VERY
interesting display.
At
the error point the VM does not
seem to be in a tight loop rather cpu is 100% on the processor and the terminal
window is sitting on this line
---FromImm---a Class (ObjectMemory)>>>doOrFinishIncrementalGC
327656
Will
--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] debugging RuntimeQuietEmergencyNotifier
|
|
In reply to this post by Will_Loew-Blosser
> In VW 7.4.1 we used RuntimeQuietEmergencyNotifier and it generated nice
> error logs. > > In 7.6 there seems to be an error during the notification that is > proving hard to track. In a development image I can generate the error > and it opens a debugger as expected. > But in a 7.6 runtimePackager built image we now have a 100% cpu usage, > no error log and none of the usual interrupts from control-Y or > shift-control-Y (emergency evaluator) work. in such situations the easiest way to find the problem is IMHO to use a C debugger (e.g. gdb) and then use the built in stack dumping routines eg. - start gdb - attach <process id> - call dumpAllToFile(1, 1) which will create a file called stack.txt containing the stack traces of all running processes. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |