primeporndirectory-website brings you the best free porn in incredible quality and variety for your satisfaction. The web is very useful if you are looking for lesbian porn, Asian porn, or beautiful Indian girls. It is a website that has a lot of potentials and that you should visit to enjoy the best porn online.
https://www.primeporndirectory.com
So, we had a new OSVM release 2023.12, tag 202312181441. Our CI built that using `Clang 17.0.6`. We bundled the binary with Squeak 5.3 #19486. Things worked.
Now, I noticed that rebuilding tag 202312181441 with the current `Clang 18.1.2` produces binaries that will immediately crash Squeak 5.3 #19486. Squeak 6.0 works and so does 6.1alpha.
[crash.dmp](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/14886860…
```
...
Crashed in the VM thread
...
Current byte code: 224
Primitive index: 0
...
Primitive trace:
Stack backtrace:
[00007ff7c554368a] __DTOR_LIST__
+ 0x7ff6853e3fc2 in Squeak.exe
[00007ff7c66442e8] ??? + 0x0 in (null)
Smalltalk stack dump:
0000009a09fce550 I CursorWithMask(Object)>isKindOf: 00007ff7c6cf0210: a(n) CursorWithMask
0000009a09fce598 I Cursor class>currentCursor: 00007ff7c66442e8: a(n) Cursor
0000009a09fce5e0 I CursorWithMask(Cursor)>show 00007ff7c6cf0210: a(n) CursorWithMask
0000009a09fce630 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 00007ff7c6688088: a(n) SmalltalkImage
7ff7c8c516d8 s SmalltalkImage>snapshot:andQuit:embedded: 00007ff7c6688088: a(n) SmalltalkImage
7ff7c8c52f28 s SmalltalkImage>snapshot:andQuit: 00007ff7c6688088: a(n) SmalltalkImage
7ff7c8c53098 s [] in ReleaseBuilder class>saveAndQuit 00007ff7c6657cd8: a(n) ReleaseBuilder
7ff7c8c53228 s WorldState>runStepMethodsIn: 00007ff7c6915f38: a(n) WorldState
7ff7c8c53320 s PasteUpMorph>runStepMethods 00007ff7c6734988: a(n) PasteUpMorph
7ff7c8c53490 s WorldState>doOneCycleNowFor: 00007ff7c6915f38: a(n) WorldState
7ff7c8c53548 s WorldState>doOneCycleFor: 00007ff7c6915f38: a(n) WorldState
7ff7c8c53610 s PasteUpMorph>doOneCycle 00007ff7c6734988: a(n) PasteUpMorph
7ff7c8c536c8 s [] in MorphicProject>spawnNewProcess 00007ff7c6af0f80: a(n) MorphicProject
7ff7c8c53780 s [] in BlockClosure>newProcess 00007ff7c8c53838: a(n) BlockClosure
stack page bytes 4096 available headroom 1480 minimum unused headroom 0
```
What is going on? I cannot rebuild tag 202312181441 with `Clang 18.1.2` to then let it run Squeak 5.3 #19486. Neither 32-bit nor 64-bit. Squeak 6.0 and 6.1alpha work. I know that tag 202312181441 used to work with Squeak 5.3 ... that's why I suspect Clang here...
The Smalltalk code after start-up that seems to trigger the crash is more or less `isKindOf:`:
```Smalltalk
Cursor normal show.
Cursor >> show
"Make the hardware's mouse cursor look like the receiver"
Cursor currentCursor: self
Cursor class >> currentCursor: aCursor
"Make the instance of cursor, aCursor, be the current cursor. Display it.
Create an error if the argument is not a Cursor."
(aCursor isKindOf: self)
ifTrue: [ "..." ]
ifFalse: [self error: 'The new cursor must be an instance of class Cursor']
```
Between Squeak 5.3 and 6.0, that code path did not change. We are still setting the normal Cursor after start-up, which invokes `currentCursor:` and then that `isKindOf:` check.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/679
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/679(a)github.com>
If a process runs alone at its original priority and bumps it higher temporarily, setting it back and yieling **will not** schedule processes above its original priority. Only if there are other processes running on that original (lower) priority.
This seems to be an older optimization in `primitiveYield`.
Here is an example:
```Smalltalk
| flag p1 p2 |
flag := Semaphore new.
p1 := [
Processor activeProcess priority: 80.
Transcript showln: 'P1 started!'.
flag signal. "activate p2"
Processor activeProcess priority: 45.
Processor yield. "fails to schedule p2"
Transcript showln: 'P1 finished!'.] newProcess.
p1 priority: 45.
p2 := [
Transcript showln: 'P2 started!'.
flag wait.
Transcript showln: 'P2 finished!'.
] newProcess.
p2 priority: 50.
p2 resume.
p1 resume.
```
Expected transcript output:
```
P2 started!
P1 started!
P2 finished!
P1 finished!
```
However, we get:
```
P2 started!
P1 started!
P1 finished!
P2 finished!
```
It is only circumstantial that P2 finishes at all because the *Timer Interrupt Scheduler* (80) will be signaled eventually and then trigger P2 (50) finally. But P1 (45) has finished by then. This is not fair.
We can show that it works as expected once another process works on the original priority (45):
```Smalltalk
| flag p1 p2 p3 |
flag := Semaphore new.
p1 := [
p3 resume.
Processor activeProcess priority: 80.
Transcript showln: 'P1 started!'.
flag signal. "activate p2"
Processor activeProcess priority: 45.
Processor yield. "fails to schedule p2"
Transcript showln: 'P1 finished!'.] newProcess.
p1 priority: 45.
p3 := [
Transcript showln: 'P3 started!'.
Transcript showln: 'P3 finished!'.
] newProcess.
p3 priority: 45.
p2 := [
Transcript showln: 'P2 started!'.
flag wait.
Transcript showln: 'P2 finished!'.
] newProcess.
p2 priority: 50.
p2 resume.
p1 resume.
```
The output is as expected:
```
P2 started!
P1 started!
P2 finished!
P3 started!
P3 finished!
P1 finished!
```
By skipping the P3 output, we get the expected order for P1 and P2:
```
P2 started!
P1 started!
P2 finished!
P1 finished!
```
The optimization in `primitiveYield` reads:
```Smalltalk
(self isEmptyList: processList) ifTrue: [^nil].
```
And so `wakeHighestPriority` will not be called in time. But I think we should support temporal priority bumping this way.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/677
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/677(a)github.com>