This I what I get in the VS2022 debugger. Of course, at the moment I do not understand the code there, but maybe hopefully Eliot can see something interesting in it. I leave VS open and look tomorrow at the code, maybe I understand a bit of it :-)
Seems there is something wrong with the forward pointers. I assume the longAt(referent) fails? I guess it is a macro, but VS could not find the definition.
########## Code area - the --> line is failing with access violation ###########
/* begin literalCountOfMethodHeader: */
assert((((header) & 7) == 1));
numLiterals = ((header >> 3)) & AlternateHeaderNumLiteralsMask;
numSlots = numLiterals + LiteralStart;
l9: /* end numStrongSlotsOf:format:ephemeronInactiveIf: */;
for (i = 0; i < numSlots; i += 1) {
referent = longAt((referrer + BaseHeaderSize) + (((sqInt)((usqInt)(i) << (shiftForWord())))));
if ((!(referent & (tagMask())))) {
/* a forwarding pointer could be because of become: or scavenging. */
--> if ((!((longAt(referent)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))))) {
/* begin followForwarded: */
assert(isUnambiguouslyForwarder(referent));
/* begin fetchPointer:ofMaybeForwardedObject: */
referent1 = longAt((referent + BaseHeaderSize) + (0U << (shiftForWord())));
while (((!(referent1 & (tagMask()))))
&& ((!((longAt(referent1)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun())))))) {
/* begin fetchPointer:ofMaybeForwardedObject: */
referent1 = longAt((referent1 + BaseHeaderSize) + (0U << (shiftForWord())));
}
referent = referent1;
########## Call stack ############
Squeak.exe!scavengeReferentsOf(__int64 referrer) Zeile 42680
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42680)
Squeak.exe!scavengeRememberedSetStartingAt(__int64 n) Zeile 42760
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42760)
Squeak.exe!scavengeLoop() Zeile 42542
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42542)
Squeak.exe!doScavenge(__int64 tenuringCriterion) Zeile 47599
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (47599)
Squeak.exe!scavengingGCTenuringIf(__int64 tenuringCriterion) Zeile 57959
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (57959)
Squeak.exe!sufficientSpaceAfterGC(__int64 numBytes) Zeile 58691
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (58691)
Squeak.exe!checkForEventsMayContextSwitch(__int64 mayContextSwitch) Zeile 62762
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (62762)
Squeak.exe!handleStackOverflowOrEventAllowContextSwitch(__int64 mayContextSwitch) Zeile 66037
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (66037)
Squeak.exe!ceStackOverflow(__int64 contextSwitchIfNotNil) Zeile 15593
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (15593)
[Externer Code]
Squeak.exe!ioInitHeartbeat() Zeile 420
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Heartbeat.c (420)
Squeak.exe!interpret() Zeile 2875
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (2875)
Squeak.exe!sqMain(int argc, char * * argv) Zeile 1761
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Main.c (1761)
Squeak.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Zeile 1851
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Main.c (1851)
[Externer Code]
########## Locals ############
classFormat 662660168776 __int64
contextSize 72198296718755736 __int64
fmt 2 __int64
foundNewReferentOrIsWeakling 0 __int64
header 140698790658008 __int64
header1 140698758633160 __int64
i 37029628 __int64
newLocation 811789632 __int64
numLiterals 64 __int64
numSlots 167772160 __int64
numSlots1 255 unsigned __int64
numSlots2 167772160 unsigned __int64
objOop1 72057594139401638 __int64
referent 139599658561184 __int64
referent1 0 __int64
referrer 140700938141704 __int64
sp 72058702004626295 __int64
############## Second try ##################
I needed to restart it again, here are my new local values in debugger
classFormat 973468582328 __int64
contextSize 72198310804720808 __int64
fmt 2 __int64
foundNewReferentOrIsWeakling 0 __int64
header 140699864399832 __int64
header1 140698758633160 __int64
i 81749860 __int64
newLocation 2070121416 __int64
numLiterals 64 __int64
numSlots 335544320 __int64
numSlots1 255 unsigned __int64
numSlots2 335544320 unsigned __int64
objOop1 72057594296693111 __int64
referent 139620721982368 __int64
referent1 0 __int64
referrer 140711869546504 __int64
sp 72058702004626295 __int64
numSlots seems to me very wrong. If I do some calculations I get also not the same value that the debugger says me. Here is the code
numLiterals = ((header >> 3)) & AlternateHeaderNumLiteralsMask;
numSlots = numLiterals + LiteralStart;
AlternateHeaderNumLiteralsMask seems to be 0x7fff
LiteralStart seems to be 1
For me is:
numLiterals = ((140699864399832 >> 3)) & 0x7fff = 32763 —> does not match the debugger local, where is the 64 coming from
Seems to me somebody has overridden already the „header“ variable, which seems to be wrong. Could it be that some other thread is writing in the wrong memory area and override my values?
Jörg
########## System Information ##############
Gerätename timemachine
Prozessor AMD Ryzen 9 3900X 12-Core Processor 3.80 GHz
Installierter RAM 32,0 GB
Geräte-ID F6FA897B-DDB1-44D6-9BF3-8BD1110AA754
Produkt-ID 00326-10048-08575-AA867
Systemtyp 64-Bit-Betriebssystem, x64-basierter Prozessor
Stift- und Toucheingabe Für diese Anzeige ist keine Stift- oder Toucheingabe verfügbar.
Edition Windows 10 Home
Version 20H2
Installiert am 23.03.2021
Betriebssystembuild 19042.1526
Leistung Windows Feature Experience Pack 120.2212.4170.0
Visual Studio 2022
win64x64\squeak.cog.spur
VM version ??? I ask Eliot how i can see that on my current local github clone and post it later
############# Code for reproducation ##############
Simply execute the following Smalltalk code. Maybe you need to run it multiple times, for me the crash happens sometimes at the 3rd or 4th try.
| oc |
oc := OrderedCollection new.
400000000 timesRepeat: [oc add: Object new]
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/614
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/614(a)github.com>
With libevdev, mouse and keyboard are bound to devices in /dev/input with names like "event0" and "event1".
Different keyboard/mouse hw binds to different numbers, so it is important to allow overrides via shell variables.
E.g.
SQUEAK_MSDEV=/dev/input/event1
SQUEAK_KBDEV=/dev/input/event0
vs
SQUEAK_MSDEV=/dev/input/event0
SQUEAK_KBDEV=/dev/input/event1
Mouse rebinding works, but not keyboard rebinding.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/575
My download folder looks pretty cluttered with names such as `squeak.cog.spur_win64x64 (3).zip`. I think it is a best practice to include the version/timestamp name of a build into the asset names. Could we maybe change the asset names to something like `osvm_202112201228_squeak.cog.spur_win64x64.zip`?
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/610
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/610(a)github.com>
SocketPlugin uses a buffer of size MAXHOSTNAMELEN + 1 on [unix](https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/6d38f13347be10….
The value of that constant is 64 on linux. A domain name can have up to 255 octets with each label having up to 63 octets.
So, 64 is definitely not the right value, nor is MAXHOSTNAMELEN, because the buffer is there to store a domain name, not a host name.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/619
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/619(a)github.com>
Observations in a current Trunk image with the latest VM RC:
- `Compiler evaluate: 'super foo' for: ProtoObject new.`
- expected: `⚡ MessageNotUnderstood: ProtoObject>>foo`
- actual: `⚡ MessageNotUnderstood: SmallInteger>>foo`
- `Compiler evaluate: 'super bitCountOfByte' for: ProtoObject new.`
- expected: `⚡ MessageNotUnderstood: ProtoObject>>bitCountOfByte`
- actual: `⚡ MessageNotUnderstood: ProtoObject>>+` from `ProtoObject(SmallInteger)>>bitCountOfByte`
Note that in the image-side simulator, method lookup for `ProtoObject` may lead to crashes at the moment:
- `Compiler evaluate: 'super foo' for: ProtoObject new.` (simulated)
- `⚡ MessageNotUnderstood: UndefinedObject>>lookupSelector:` from `Context>>send:to:with:lookupIn:`
I will happy to fix the image-side bugs to align them to the VM behavior. As for the VM side, it would be an interesting task, but would require more familiarization for me. 😉
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/629
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/629(a)github.com>
As of https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2d7105db755928fd90…, the image side can access native pixels only for "native Retina" scale factors as the platform code only considers the `backingScaleFactor`. Currently, this will only change between "1.0" and "2.0" depending on your display. Maybe at some day, there will be displays with "3.0". Who knows.
It would be nice if we could also support that other/older scaling, which mimicks other resolutions.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/628
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/628(a)github.com>
Hi Folks,
I just discovered that the recent 202204190959 Mac VM includes Tobias
HiDpi support on the Mac. This is very good news indeed, but It is not
exactly what most users would prefer.
On a Retina MacBook, you can set an apparent display resolution (System
Preferences.../ Displays). By default, my 2019 15" MBP suggest half
"real" resolution ("Looks like 1440x900" when LCD is 2880x1800). In this
case, the new VM offers the true native resolution to Cuis / Squeak. So,
in this case, it works perfectly well, and everything looks really great.
The problem is that MacOs supports several other apparent resolutions.
Many people, me included, prefer "Looks like 1680x1050" or "Looks like
1920x1200") to have more room for other Mac apps. But in these cases,
the VM doesn't offer the LCD native resolution to Cuis / Squeak anymore.
It offers twice the apparent resolution, i.e. 3360x2100 or 3840x2400.
Then MacOs scales this higher virtual resolution to the actual
2880x1800, but it generates visual artifacts and a decrease in visual
quality.
For my own private use, the solution is to use the EasyRes application,
and set the display to the true 2880x1800 resolution. When I do this,
Cuis gets the corrrect Display size both with previous and newer VMs.
But it would be great if there was a way for other Cuis / Squeak users
to get their true Display resolution by default, and without needing to
change OS settings each time they start their favorite Smalltalk.
Thanks,
--
Juan Vuletich
www.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3https://independent.academia.edu/JuanVuletichhttps://www.researchgate.net/profile/Juan-Vuletichhttps://patents.justia.com/inventor/juan-manuel-vuletichhttps://twitter.com/JuanVuletich