Debugging the new compactor and the SocketPlugin ;-)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging the new compactor and the SocketPlugin ;-)

Eliot Miranda-2
 
Hi All,

    I'm having a blast writing and debugging the new compactor.  I've got to the stage where, in a real VM, I can load and save images and run global garbage collect fairly reliably, but when I go through a sequence of

    check changes on a package in the Monticello Browser
    attempt to save these changes
    receive warning that there's a more up-to-date version
    update the image

I reliably get a crash.

Now in the simulator I'm using lemming debugging to be able to endlessly repeat a failing GC, with the original heap unchanged as a reference, hence having a blast, cuz this makes it relatively easy to debug.  But in the real VM I would have to implement a fair ammount to reproduce lemming debugging

    - forking the process on GC
    - running the GC in the child
    - catching the exit status
    - raising an exception in the parent to allow the debugger to attach
    - being able to proceed from the exception by repeating the fork and the GC, etc...

And yet if and when I did this I would still have nothing like the debuggability I have in the simulator.

To be able to reproduce the original sequent in the Simulator I also need a fair amount, to be specific, I need a simulate able SocketPlugin.  This means implementing some subset of #sqResolverAbort #sqResolverAddrLookup:Result: #sqResolverAddrLookupResultSize #sqResolverError #sqResolverGetAddressInfoFamily #sqResolverGetAddressInfoHost:Size:Service:Size:Flags:Family:Type:Protocol: #sqResolverGetAddressInfoNext #sqResolverGetAddressInfoProtocol #sqResolverGetAddressInfoResult:Size: #sqResolverGetAddressInfoSize #sqResolverGetAddressInfoType #sqResolverGetNameInfo:Size:Flags: #sqResolverGetNameInfoHostResult:Size: #sqResolverGetNameInfoHostSize #sqResolverGetNameInfoServiceResult:Size: #sqResolverGetNameInfoServiceSize #sqResolverHostNameResult:Size: #sqResolverHostNameSize #sqResolverLocalAddress #sqResolverNameLookupResult #sqResolverStartAddrLookup: #sqResolverStartName:Lookup: #sqResolverStatus #sqSocket:AcceptFrom:RecvBytes:SendBytes:SemaID: #sqSocket:AcceptFrom:RecvBytes:SendBytes:SemaID:ReadSemaID:WriteSemaID: #sqSocket:BindTo:Port: #sqSocket:BindToAddress:Size: #sqSocket:ConnectTo:Port: #sqSocket:ConnectToAddress:Size: #sqSocket:CreateNetType:SocketType:RecvBytes:SendBytes:SemaID: #sqSocket:CreateNetType:SocketType:RecvBytes:SendBytes:SemaID:ReadSemaID:WriteSemaID: #sqSocket:CreateRaw:ProtoType:RecvBytes:SendBytes:SemaID:ReadSemaID:WriteSemaID: #sqSocket:ListenBacklog: #sqSocket:ListenOnPort: #sqSocket:ListenOnPort:BacklogSize: #sqSocket:ListenOnPort:BacklogSize:Interface: #sqSocket:LocalAddressResult:Size: #sqSocket:ReceiveDataBuf:Count: #sqSocket:ReceiveUDPDataBuf:Count:address:port:moreFlag: #sqSocket:RemoteAddressResult:Size: #sqSocket:SendDataBuf:Count: #sqSocket:toHost:port:SendDataBuf:Count: #sqSocketAbortConnection: #sqSocketAddress:Size:SetPort: #sqSocketAddress:SizeGetPort: #sqSocketCloseConnection: #sqSocketConnectionStatus: #sqSocketDestroy: #sqSocketError: #sqSocketGetOptions:optionNameStart:optionNameSize:returnedValue: #sqSocketLocalAddress: #sqSocketLocalAddressSize: #sqSocketLocalPort: #sqSocketReceiveDataAvailable: #sqSocketRemoteAddress: #sqSocketRemoteAddressSize: #sqSocketRemotePort: #sqSocketSendDone: #sqSocketSetOptions:optionNameStart:optionNameSize:optionValueStart:optionValueSize:returnedValue:

;-)

(BTW, the implementation strategy, as it is with the FilePluginSmulator, is to fall back on the host image's facilities; probably simpler with the SocketPlugin than the FilePlugin because there's no need to fake up directory entries and the like - at least I hope so).

Now being able to simulate images that use sockets is probably quite useful.  And I'm leaning toads having a go, but have no idea how long its going to take (I don't know the subset of the above that will need to be implemented to get image update to simulate fully).

So has anyone else had any experience here?  Got a SocketPluginSimulator you've hidden away for a rainy day?  Think its way too difficult and I should implement lemming debugging for real?
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Debugging the new compactor and the SocketPlugin ;-)

Levente Uzonyi
 
That's a rather long list of primitives.
Most images only use the resolver primitives, and optionally the TCP
primitives. If it's a Squeak image and useOldNetwork is enabled, then you
don't have to implement the new network primitives either.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Debugging the new compactor and the SocketPlugin ;-)

timfelgentreff
 

Eliot, in RSqueak we only implement exactly those primitives you need to run an update. If you check https://github.com/HPI-SWA-Lab/RSqueak/blob/master/rsqueakvm/plugins/socket_plugin.py there are only 13 primitive functions that do not simply print "Missing primitive". Those are all you need.


Levente Uzonyi <[hidden email]> schrieb am Do., 29. Dez. 2016, 00:21:

That's a rather long list of primitives.
Most images only use the resolver primitives, and optionally the TCP
primitives. If it's a Squeak image and useOldNetwork is enabled, then you
don't have to implement the new network primitives either.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Debugging the new compactor and the SocketPlugin ;-)

timfelgentreff
 

I could have said, the implemented primitives are all at the bottom of that file.


Tim Felgentreff <[hidden email]> schrieb am Do., 29. Dez. 2016, 10:25:

Eliot, in RSqueak we only implement exactly those primitives you need to run an update. If you check https://github.com/HPI-SWA-Lab/RSqueak/blob/master/rsqueakvm/plugins/socket_plugin.py there are only 13 primitive functions that do not simply print "Missing primitive". Those are all you need.


Levente Uzonyi <[hidden email]> schrieb am Do., 29. Dez. 2016, 00:21:

That's a rather long list of primitives.
Most images only use the resolver primitives, and optionally the TCP
primitives. If it's a Squeak image and useOldNetwork is enabled, then you
don't have to implement the new network primitives either.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Debugging the new compactor and the SocketPlugin ;-)

Eliot Miranda-2
In reply to this post by Levente Uzonyi
 


On Wed, Dec 28, 2016 at 3:20 PM, Levente Uzonyi <[hidden email]> wrote:

That's a rather long list of primitives.
Most images only use the resolver primitives, and optionally the TCP primitives. If it's a Squeak image and useOldNetwork is enabled, then you don't have to implement the new network primitives either.

Right.  Worry not.  I'm implementing as simulation proceeds, so I'll implement the minimum necessary.  I realise I may be able to get away with updating from a local repository, but I'm having fun implementing the SocketPluginSimulator so for now I'll continue on this route.

_,,,^..^,,,_
best, Eliot