GC bug

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

GC bug

MrGwen
Hi,


There is an inifinite loop in the queue_put function. To reproduce it :

open the implementor tool (ctrl+m)
type add:before:
and select OrderedCollection>>#add:before:

it was on the git commit 0757a0cddd4df0153508069f47286cbc415f56c3

Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

bug_repport.tar.bz (124K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GC bug

Paolo Bonzini-2
On 03/12/2010 11:16 AM, Gwenael Casaccio wrote:

> Hi,
>
>
> There is an inifinite loop in the queue_put function. To reproduce it :
>
> open the implementor tool (ctrl+m)
> type add:before:
> and select OrderedCollection>>#add:before:
>
> it was on the git commit 0757a0cddd4df0153508069f47286cbc415f56c3

maybe the same, from IRC:

gst 4c508c1
visualgst 79cadb0f9f3694e61ce0c7b9184553d0fbd42e8f

open the implementor, select includesAny and select it in the result
list. And the vm crashes.

scanned_fields_in (object=0x7ffff7fdd848, flags=262144) at oop.c:1937
_gst_copy_an_oop (oop=0x2ad206bb8c30) at oop.c:2076
_gst_copy_registered_oops () at callin.c:1095
copy_oops () at oop.c:1754
_gst_scavenge () at oop.c:1226
alloc_new_chunk (sendSelector=<value optimized out>, sendArgs=0,
receiver=0x2ad206bd01f0, method_class=<value optimized out>) at interp.c:788
alloc_stack_context (sendSelector=<value optimized out>, sendArgs=0,
receiver=0x2ad206bd01f0, method_class=<value optimized out>) at interp.c:829
activate_new_context (sendSelector=<value optimized out>, sendArgs=0,
receiver=0x2ad206bd01f0, method_class=<value optimized out>) at interp.c:852

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GC bug

Paolo Bonzini-2
On 06/05/2010 01:25 PM, Gwenaël Casaccio wrote:

> Try (Collection >> #includes:) = (Collection >> #includesAnyOf:)
>
> CompiledBlock>>= aMethod [
> "Answer whether the receiver and aMethod are equal"
>
> <category: 'basic'>
>      self == aMethod ifTrue: [^true].
>      ^super = aMethod and: [method = aMethod method]
>      ]
>
> [method = aMethod method], this is the bug we will have an infinite loop
> => the CompiledMethod>>#= will again checks the literals which store the
> same blocks ...

Great, thanks!

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GC bug

MrGwen
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

cmpCode.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GC bug

Paolo Bonzini-2
On 06/05/2010 07:18 PM, Gwenaël Casaccio wrote:
> Here is the patch,
>
> since we check that each instance variables and bytecode are the same.
> I consider that we're doing an identity comp. (if all fields are the same).
> I've launched make check I didn't see a regression.

I hesitated a bit, but then concluded that the potential for breaking
the browser using ##(...) is too big unless identity is used.  It is
also quite faster.

I made the change, except I used the primitive directly.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk