Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Littergators resolve disputes about rubbish
Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm... Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org: Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Littergators resolve disputes about rubbish
...this is probably due to cycles in the object graph:
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm... Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org: Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Littergators resolve disputes about rubbish
Ha. Looks like that #rehash does better fit in Object >> #readDataFrom:size:. See Kernel-mt.1526 and System-mt.1424. SqueakMap Catalog should update again fine in Trunk again. :-)
Best, Marcel Am 27.09.2023 11:15:25 schrieb Marcel Taeumel marcel.taeumel@hpi.de: ...this is probably due to cycles in the object graph:
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm... Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org: Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Littergators resolve disputes about rubbish
Great. Do we already have a test for this? Should we? :-)
________________________________ From: Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org Sent: Wednesday, September 27, 2023 1:41:44 PM To: gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org Cc: Marcel Taeumel marcel.taeumel@hpi.de Subject: [squeak-dev] Re: SqueakMap 'Update' fails on Squeak trunk but ok on 5.3
Ha. Looks like that #rehash does better fit in Object >> #readDataFrom:size:. See Kernel-mt.1526 and System-mt.1424. SqueakMap Catalog should update again fine in Trunk again. :-)
Best, Marcel
Am 27.09.2023 11:15:25 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
...this is probably due to cycles in the object graph:
[cid:eb4e83e9-b57c-4b62-9d48-9c306ec3e12b]
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm...
Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org:
Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary [cid:afd758eb-6413-439f-af4e-e79ed05ef63f@hpi.uni-potsdam.de]
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Littergators resolve disputes about rubbish
Nice catch. Interesting that the entire Dictionary didn't get read yet; certainly counter-intuitive. Looks to me like the SmartRefStream>>next & ReferenceStream>>next are confusing the issue by claiming the object has been read (which I guess it has, really) even though its instvars have not, yet.
On 2023-09-27, at 2:15 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
...this is probably due to cycles in the object graph:
<image.png>
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm...
Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org:
Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary <Screen Shot 2023-09-26 at 6.05.19 PM.png>
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Littergators resolve disputes about rubbish
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as the IRS kicked his door in.
Hi Marcel,
Wouldn't #comeFullyUpOnReload: be the official method in which to place the rehashing?
For what it's worth, it is invoked a few lines (not counting the comments) later in DataStream>>next (readDataFrom:size: is sent during the perform: in the middle of DataStream>>next).
Kind regards, Jakob
Am Mi., 27. Sept. 2023 um 19:41 Uhr schrieb Tim Rowledge tim@rowledge.org:
Nice catch. Interesting that the entire Dictionary didn't get read yet; certainly counter-intuitive. Looks to me like the SmartRefStream>>next & ReferenceStream>>next are confusing the issue by claiming the object has been read (which I guess it has, really) even though its instvars have not, yet.
On 2023-09-27, at 2:15 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
...this is probably due to cycles in the object graph:
<image.png>
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm...
Am 27.09.2023 03:08:22 schrieb Tim Rowledge tim@rowledge.org:
Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary <Screen Shot 2023-09-26 at 6.05.19 PM.png>
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Littergators resolve disputes about rubbish
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as the IRS kicked his door in.
Hi Jakob --
Wouldn't #comeFullyUpOnReload: be the official method in which to place the rehashing?
Aha! Thanks. See Collections-mt.1051. The actual cause of the bug was
in HashedCollection >> #comeFullyUpOnReload: :-)
Best, Marcel Am 27.09.2023 20:07:46 schrieb Jakob Reschke jakres+squeak@gmail.com: Hi Marcel,
Wouldn't #comeFullyUpOnReload: be the official method in which to place the rehashing?
For what it's worth, it is invoked a few lines (not counting the comments) later in DataStream>>next (readDataFrom:size: is sent during the perform: in the middle of DataStream>>next).
Kind regards, Jakob
Am Mi., 27. Sept. 2023 um 19:41 Uhr schrieb Tim Rowledge :
Nice catch. Interesting that the entire Dictionary didn't get read yet; certainly counter-intuitive. Looks to me like the SmartRefStream>>next & ReferenceStream>>next are confusing the issue by claiming the object has been read (which I guess it has, really) even though its instvars have not, yet.
On 2023-09-27, at 2:15 AM, Marcel Taeumel via Squeak-dev wrote:
...this is probably due to cycles in the object graph:
So, we probably should not call #rehash on objects that are incomplete there due to cycle detection. Hmm...
Best, Marcel
Am 27.09.2023 10:55:05 schrieb Marcel Taeumel :
Hmm... we added extra #rehash sends in 2022 to SmartRefStream >> #next. That's why the behavior changed from 5.3/6.0 to 6.1alpha. Hmm...
The dictionary in question is the "objects" instVar for the central instance of SMSqueakMap. it interesting thing is that it passes twice through SmartRefStream >> #next. The first time with an invalid array and the second time complete and re-hash-able. Hmm...
Am 27.09.2023 03:08:22 schrieb Tim Rowledge :
Whilst updating the SM entries for MQTT etc I went to update the SM tool and it fails when reading the update map. The issue appears to be that deep in the process a Dictionary exists that has a tally of 4162 but an array of nil. Which doesn't seem quite proper somehow.
The starting point is SMLoaderPlus>loadUpdates but a long way later we get to SmartRefStream>>#readInstanceSize:clsname:refPosn: with a refPosn of 1270478. A couple of methods later we try to rehash the Dictionary
This can never end well.
There's no way I have time to do anything much with this, so volunteers needed...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Littergators resolve disputes about rubbish
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as the IRS kicked his door in.
squeak-dev@lists.squeakfoundation.org
-
Jakob Reschke -
Marcel Taeumel -
Thiede, Christoph -
Tim Rowledge