[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] try appveyor (bed86c5)
Nicolas Cellier
nicolas.cellier.aka.nice at gmail.com
Mon May 15 22:19:58 UTC 2017
2017-05-15 17:39 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
> Hi Nicolas,
>
> On Mon, May 15, 2017 at 7:37 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> Hi Eliot,
>> I've not worked on it for a month or so, but last time I tried, the VM
>> failed during image startup.
>> AFAIR, it had time to produce and execute some JIT, but I can't say more
>> until I have access to my laptop this evening,
>> I've tried some crazy things like tracing every VM function thru gdb
>> hack, unfortunately, it does not scale (slow) and also perturbates the VM.
>> I'll try to report ASAP.
>>
>> There's a first thing needed before testing it:
>> either add some -DWIN64ABI compilation flag somewhere, or add these 3
>> lines in cogit.c preamble
>>
>> #if WIN64
>> # define WIN64ABI 1
>> #endif
>>
>
> I was thinking it would be natural to add it to the build.win64x64
> makefiles. But I've hacked something up to add the above to cogit.c.
>
>
Yes thanks, if it can work automagically then it's better.
About Win64 status, maybe you remember the thread opened on vm-dev in March
2017, where I mentionned the error:
(gdb)
Continuing.
Breakpoint 5, enterCogCodePopReceiver () at ../../spur64src/vm/
cogitX64WIN64.c:5171
5171 realCEEnterCogCodePopReceiverReg();
(gdb)
Continuing.
Breakpoint 6, 0x000007fefd4ce547 in msvcrt!longjmp () from
/cygdrive/c/Windows/system32/msvcrt.dll
(gdb) call printCallStack()
0xf0b138 I Set class(HashedCollection class)>new 0xb9f8ee8: a(n)
Set class
0xf0b168 M FFICallbackThunk class>startUp: 0xd06b718: a(n)
FFICallbackThunk class
0xf0b1c0 M [] in SmalltalkImage>send:toClassesNamedIn:with:
0xba53d18: a(n) SmalltalkImage
0xf0b210 I OrderedCollection>do: 0xbda81d8: a(n) OrderedCollection
0xf0b260 I SmalltalkImage>send:toClassesNamedIn:with: 0xba53d18:
a(n) SmalltalkImage
0xf0b2b8 I SmalltalkImage>processStartUpList: 0xba53d18: a(n)
SmalltalkImage
0xf0b310 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded:
0xba53d18: a(n) SmalltalkImage
0xc6187b0 s SmalltalkImage>snapshot:andQuit:embedded:
0xbc9ee20 s SmalltalkImage>snapshot:andQuit:
...snip...
(gdb) print reenterInterpreter
$26 = {{Part = {15766176, 4294967295}}, {Part = {15766176, 15975296}},
{Part = {65001, 0}}, {Part = {4294967295, 8}}, {Part = {
1998004096, 15989488}}, {Part = {4356103, 3843995738016}}, {Part =
{0, 0}}, {Part = {0, 0}}, {Part = {0, 0}}, {Part = {0, 0}},
{Part = {0, 0}}, {Part = {0, 0}}, {Part = {0, 0}}, {Part = {0, 0}}, {Part
= {0, 0}}, {Part = {0, 0}}}
(gdb) cont
Continuing.
[Thread 1912.0x4e4 exited with code 0]
gdb: unknown target exception 0xc0000028 at 0x77438078
Program received signal ?, Unknown signal.
0x0000000077438078 in ntdll!RtlRaiseStatus () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) where
#0 0x0000000077438078 in ntdll!RtlRaiseStatus () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1 0x00000000773d7eb6 in ntdll!TpAlpcRegisterCompletionList () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2 0x000007fefd4ce5a3 in msvcrt!longjmp () from
/cygdrive/c/Windows/system32/msvcrt.dll
#3 0x00000000004314f9 in returnToExecutivepostContextSwitch
(inInterpreter=0, switchedContext=0)
at ../../spur64src/vm/gcc3x-cointerp.c:22130
#4 0x000000000043a110 in activateNewMethod () at ../../spur64src/vm/gcc3x-
cointerp.c:15045
#5 0x000000000043c6e2 in interpretMethodFromMachineCode () at
../../spur64src/vm/gcc3x-cointerp.c:19204
#6 0x0000000000442e19 in ceSendsupertonumArgs (selector=192910456,
superNormalBar=0, rcvr=195006184, numArgs=0)
at ../../spur64src/vm/gcc3x-cointerp.c:17228
#7 0x000000000ac000ba in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
----------------------
It was quite long to execute the VM step by step, several setjmp/longjmp
did succeed before the failing one, and I had got no idea which bug I was
looking for, nor were enough exercized to decipher the C stack and/or the
Smalltalk stack (in which variable they are stored etc...).
So I tried a different angle of attack in end of March: let's trace the VM
actions and then trace back from the failing point. Maybe it would give me
a clue.
My idea was to exploit something like:
http://stackoverflow.com/questions/311840/tool-to-trace-loca
l-function-calls-in-linux#311912
Of course, cygwin is a strange linux, so I tried with dumbin, but the
address were wrong.
Finally it did work OK with objdump, see the final make_trace attached.
Unfortunately, the debug VM traced by gdb does block before encountering
the error (despite a few grep -v attempts to not catch the heartbeat).
My crazy ideas do not seem to work...
I also managed to get a gdb.exe.stackdump if asking to trace too many
functions.
I attach a gdb.log though for the curious.
Since then I had no time to work on it. It requires a more intimate
understanding of stack organization and other VM details. I'm not ready yet.
> 2017-05-15 16:24 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>>
>>> Hi Nicolas,
>>>
>>> can you give a short status report on Cog for Win64? What is not
>>> working for the JIT? Given that the stack spur vm works we should be
>>> close. So what still needs fixing?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>> On May 15, 2017, at 7:13 AM, Nicolas Cellier <notifications at github.com>
>>> wrote:
>>>
>>> Hi Esteban, currently this fails because with don't build pharo.cog.spur
>>> yet in win64.
>>> Could you retry with "${ROOT_DIR}/build.${ARCH}/pharo.*stack*
>>> .spur/build/vm"?
>>> At least, this should turn the appveyor status green again.
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/bed86c5723c150a7eafad111a1872d739dcbae97#commitcomment-22142928>,
>>> or mute the thread
>>> <https://github.com/notifications/unsubscribe-auth/APHa0DePieA9856_kWXXScvpTMsyykRTks5r6F1-gaJpZM4NbMVh>
>>> .
>>>
>>>
>>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170516/7675a376/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_trace
Type: application/octet-stream
Size: 1088 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170516/7675a376/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.log
Type: application/octet-stream
Size: 587930 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170516/7675a376/attachment-0003.obj>
More information about the Vm-dev
mailing list