Hi,
recently the vw is
crashing sometimes, but not always, with the following message (from the
debug vm):
------------------------------
Assert fail @ 312 in
stack\send.c
isTranFailCode(nm)
VisualWorks(R) 7.4d Oct 24 2006 [ thapi com ephemerons immutability debug assert ] Fatal error: unexpected translation failure (selector 'ihiDAX'), code = 2 Space could not be allocated.
------------------------------ Context:
WinXP sp2,
Intel Core2Duo 6300, 2 GB, VW 7.4.1
The code
retrieves data from Bloomberg and with the result I compile a method (in this
case #ihiDAX). This results in the crash. Unfortunately this is not
deterministic, since this succeeds most of the time. Also, in this case the
generated method is not big (sometimes I get methods with a couple of megebytes
source without problems).
Also, with
this particular case, the image was just startet, but I get it also after many
hours of work after lots of requests which succeed. And, yes, I do have enough
memory in my box.
cheers,
Christian
|
Christian, did you see Joachim Geidel's message on this subject (on the
18th)? He reports ... which attempts to flush the method cache for the new method's selector by using #flushVMmethodCacheEntriesFor:. Apparently, this is not sufficient. That suggests you need to experiment a bit with how you flush the code cache - see if it works better if you use the more expensive #flushVMmethodCache instead. R - > Hi, > > recently the vw is crashing sometimes, but not always, with the > following message (from the debug vm): > ------------------------------ > Assert fail @ 312 in stack\send.c isTranFailCode(nm) > VisualWorks(R) 7.4d Oct 24 2006 > [ thapi com ephemerons immutability debug assert ] > Fatal error: unexpected translation failure (selector 'ihiDAX'), code = 2 > > Space could not be allocated. > ------------------------------ > > Context: > WinXP sp2, Intel Core2Duo 6300, 2 GB, VW 7.4.1 > > The code retrieves data from Bloomberg and with the result I compile a > method (in this case #ihiDAX). This results in the crash. Unfortunately > this is not deterministic, since this succeeds most of the time. Also, > in this case the generated method is not big (sometimes I get methods > with a couple of megebytes source without problems). > > Also, with this particular case, the image was just startet, but I get > it also after many hours of work after lots of requests which succeed. > And, yes, I do have enough memory in my box. > > cheers, > Christian > > > Smalltalked Visuals GmbH > Christian Haider > Wiesbaden, Germany > http://www.smallCharts.de <http://www.smallcharts.de/> > |
In reply to this post by Christian Haider-2
Sorry for the false alarm - forunately it is not the code generation part!
The bug (if it would qualify as one) is with
executing a method with a couple of cascades (a lot
:-).
Attached is a method with reproduces
the problem. If anyone is interested, file-in the method in a virgin
visual.im.
Executing it (with a doit on the method comment) will
succeed (on my machine).
If you scroll down to "(Date newDay: 13 monthNumber: 5
year: 2005) asTimestamp" you'll find a comment with some explanantion. The rest
of the cascade is commented out. If you uncomment one more #add: statement,
executing the method will crash the image (on my machine - the crash
provoking number of statements might be different on your
machine).
Interestingly, if you you just select the whole thing
(except for the method selector), and inspect-it, you will get a nice error
notification with a primitive
failed.
Obviously, I hit a vm limit for cascades (for this
method on my machine it is 2081 - 2082 will exceed the stack space and crash).
The limit depends on the concrete code; the original method had a few
more method calls and crashed at
2054.
This behavior is not too critical for me, but
just good to know.
The bug, in my opinion, is that the vm crashes. It
would be so much nicer if it could also raise a primitive failed like it does
when interpreting the code.
Cheers,
Christian
Object class-ihiDAXPrimitiveFailed.st (393K) Download Attachment |
On 2/23/07, Christian Haider <[hidden email]> wrote:
There is an AR for this. What's happening is that the generated native method is too large to fit in the native code cache. Try increasing the size (see ObjectMemory class>>setSizesAtStratup:). Before I left Steve Dahl and I had discussed that a good response would be for the translator to always fail to translate methods above a certain size (say 5k bytecodes) and cause a message to be sent to the context, e.g. Context>>methodTooLargeToTranslate, and have contxts respiond to this by interpreting their method.
|
Free forum by Nabble | Edit this page |