9.2.2 OSStructure>>#uint32At:put: yields PrimitiveFailed

44 views
Skip to first unread message

Joachim Tuchel

unread,
Jul 31, 2020, 4:02:21 AM7/31/20
to VA Smalltalk
Hi,

I'm porting an app from 9.1 to 9.2.2. A code snippet that has been working before now breaks with a PrimitiveFailed Error.

The method I am calling is implemented on a Subclass of OSStructure and sends itself uint32At:put: like this:

pin: someString
  self uint32At: 8 put: someString asPSZ copyToOSMemory.

This has been working in 9.1 but now fails in OSPtr>>#uint32At:put:. inspecting self primitiveErrorCode reveals 2, which is named PrimErrIndexOutOfRange.

What's interesting is that neither OSStructure>>#uint32At:put: nor OSPtr>>#uint32At:put: have changed since 2015, so I guess something changed in the underlying primitive which makes it less tolerant towards the error I have been making all these years...?

What can I do now? I couldn't find anything in the Migration Guide (at least nothing I would understand. The only mention of uint32At: is associated with EsEntryPoints, which I am not using here, also OSStriucture and OSPtr aren't found in the MG)

Joachim



Joachim Tuchel

unread,
Jul 31, 2020, 4:16:28 AM7/31/20
to VA Smalltalk
Maybe I should mention that this code has been running on 9.1x64 bits and now I am also using 9.2.2x64 bits.

Other things I tried and that failed:

  1. passing 'Test' asPSZ (invalid class in argument 2)
  2. passing 'Test' asPSZ copyToOSMemory address (Value out of range)
  3. passing 'Test' asPSZ copyToOSMemory reference (Value out of range)
  4. passing 'Test' (invalid class in argument 2)

Joachim Tuchel

unread,
Jul 31, 2020, 5:03:33 AM7/31/20
to VA Smalltalk
I wrote a little Test Class demonstrating my problem. It is just one class named JtOSStructureTest which subclasses OSStructure. It has two members: version and pin.
You can load this Application into a 9.1x64 image and inspect JtOSStructureTest testThisClass

While this runs in 9.1, it yields an error in 9.2, stack is attached

Here is what the Transcript says about the 9.1 image VM (where the code runs):
VA Smalltalk V9.1 (64-bit); Image: 9.1 [413]
VM Timestamp: 4.0, 07/18/18 (100)


And this is where it fails:
VA Smalltalk V9.2.2 (64-bit); Image: 9.2.2 [2]
VM Timestamp: 4.0, 05/15/20 (102)


I am almost sure I am doing it wrong. But I don't see where. Any hint is greatly appreciated


stack_922.txt
JtOSStructureTest.dat.txt

Joachim Tuchel

unread,
Jul 31, 2020, 8:39:23 AM7/31/20
to VA Smalltalk
Just for completeness: if I do:

self uint32At: #pin put: someString asPSZ copyToOSMemory.

I also get a PrimitiveFailed

Joachim Tuchel

unread,
Jul 31, 2020, 8:53:19 AM7/31/20
to VA Smalltalk
Okay, thanks for reading, or at least giving me the opportunity to write my progress down. I found my error. I shouldn't use uint32At: for pointers. It's muuuuch better to use pointerAt:

A bit emberassed but happy ;-)

Joachim

Seth Berman

unread,
Jul 31, 2020, 9:35:30 AM7/31/20
to VA Smalltalk
Hi Joachim,

You are correct, pointerAt:, pointerAt:put: for addresses.

We've had several changes since that time which may be the reason you are now seeing it in 9.2
1. We use the clang compiler now...which has a different allocator.
2. We compile with security features like high-entropy 64-bit address space layout randomization (ASLR) that would also impact this.

The bottom line is, you were just getting lucky in 9.1 that the allocator happened to be allocating memory < 4GB on 64-bit.

In any case, glad you found it.

- Seth

Joachim Tuchel

unread,
Jul 31, 2020, 10:51:10 AM7/31/20
to VA Smalltalk
Seth,

Yeah, I was suspecting that it is something that had been working in 9.1 "by accident"... it just took me some time to find out what this something might be. I can't even tell any more what triggered the idea that my use of uint32At:/put: could be the problem...

Just a side comment: I am more or less done porting Kontolino! from VAST 9.1 to VA 9.2.2 and this one was my hardest issue. The rest went smooth and everything was documented in the migration guide. I have two more areas to look at:

  • Glorp: I have added quite a few "fixes" to Glorp over the years, and since there is no obvious process of getting such things back into the Glorp code base (or not if the idea is dumb), but some of the topics had been discussed with Niall Ross and others a few years ago, some changes in the "official" Glorp version might be fixes to problems I reported, but a different implementation from mine
  • XD Packaging a headless image. I can't comment on this yet, haven't tried yet. I can load the code into a passive image but have been dsitracted from next steps.
So I must say the transition went really well. Good job guys! I am impressed by how smooth migrations go every time.


Joachim


Seth Berman

unread,
Jul 31, 2020, 11:33:31 AM7/31/20
to VA Smalltalk
Thank you Joachim,

That means a lot to the team to hear.  We spend a lot of energy keeping a migration path available
for reasons like this.  There have been a couple of new customers this year that successfully
migrated their systems from Visualage 6.0 with minimal difficulty.  And that's a big deal.

We don't think we're perfect at it, but as far as an industry-standard goes, we think we do it better than most.
And the reason we do this, rather than taking the easy path of just breaking old stuff, is that we recognize how
much investment has gone into these systems over the many years.  And its in our company DNA to respect
and support that.

So the team says "Much appreciated!"

- Seth
Reply all
Reply to author
Forward
0 new messages