Unusual Crash (VMTRAP)

76 views
Skip to first unread message

Neil Morrison

unread,
Aug 11, 2025, 9:17:07 PMAug 11
to VAST Community Forum
Hi all,

Hoping someone can offer some advice on an issue we recently encountered.

Platform: Windows 10
Smalltalk: v13

Our application (now 26yrs old) has been running happily for a very long time.
Recently we started encountering application crashes (VMTraps).

I've worked forwards from a known working version to the failing version and limited the issue to appear to be caused by an innocuous change, no different to any other change made over many years.

To resolve I simply edited the methods that changed - so effectively no change but recompiled none the less.
Voila, application back to being stable again!!!

I question relates to whether there is a way of going over all the code in the system and compiling it and comparing the resulting bytecode say to that stored in Envy.

Or alternatively any other suggestion as how this may occur

The VMtraps manifest something like the following:

-Walkbacks-------------------------------
<broken-class-038652B5>:<nil> {running,1}
P2SESecurityTabsPanel-class>>abtUntranslatedConstants
OSFuncdesc>>wFuncFlags
CwAppContext>>suspendSmalltalk


The trap file is different every time but always shows as a broken-class?

Neil Morrison
Principal Developer
Royal New Zealand Police

Henry Johansen

unread,
Aug 12, 2025, 12:56:24 PMAug 12
to va-sma...@googlegroups.com
Hi Neil!

That sounds like an issue we wouldn't mind investigating closer.
If you open a support case, we can allocate a task to (at least) create a script to do the bytecode comparison you are asking for.

Cheers,

Henry Johansen

VAST Consultant

Senior Software Engineer




 hjoh...@instantiations.com
 instantiations.com



Twitter LinkedIn VAST Community Forum GitHub YouTube pub.dev


--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/0c895dff-6be7-4d9e-aa29-bcc607f856fen%40googlegroups.com.

Richard Sargent

unread,
Aug 14, 2025, 1:15:58 PMAug 14
to VAST Community Forum
Neil,

That broken-class-... business looks more like a Process than a class.
e.g.
UIProcess:(2025-08-14 09:53:20){running,3}
Process:Idle 09:52:53{ready,1}
Process:CwAsyncIOProcess{suspended,4}
(*Process instances shown in an Inspector window. Why the stack dump would not be able to print the class name is beyond me. Having a nil process name is certainly allowed, per Process>>#processName.)

Can you find the string broken-class in your image?
Is there any chance you have created your own subclass of Process? (I can't really imagine doing so, but ...)
The #abtUntranslatedConstants all simply answer a literal Array of Strings, so why that method would fail is indeed a mystery.
In fact, that stack dump just doesn't make sense. None of those methods sends the next. But, I guess that's why it's so puzzling to you.

Neil Morrison

unread,
Aug 15, 2025, 7:21:58 PMAug 15
to VAST Community Forum
Yeah - not creating processes - just clicking in the UI

The vm trap logs often refer to classes that the user is nowhere and unlikely to have ever visited
Odd indeed!!

Problem is resolved by editing/saving the code - problem is finding that code.
I've started with the last working known map and working forwards, doing a build and running the app (multiple times) and wait for it to crash (anywhere between 1min and 24hrs+).

Instantiations are looking to provide a script that can verify the bytecode against the source code - should speed up the process in case it happens again in the future

Regards,

N
Reply all
Reply to author
Forward
0 new messages