Is this normal (caught segv during mem_alloc)?

I noticed this while perusing the super long output
from truss earlier today :

4685/1:   <- libgst:_gst_empty_context_pool() = 0xfac02800
4685/1:   -> libgst:_gst_tenure_all_survivors(0xfac02800, 0xff36a3b0,
0x0, 0x7)
4685/1:     -> libgst:_gst_tenure_oop(0xfac1c198, 0x0, 0x0, 0x0)
4685/1:       -> libgst:_gst_mem_alloc(0x3796e0, 0x14, 0x0, 0x0)
4685/1:    Incurred fault #6, FLTBOUNDS  %pc = 0xFF2DA7F8
4685/1:      siginfo: SIGSEGV SEGV_ACCERR addr=0xEA9AA010
4685/1:         -> libsigsegv:sigsegv_handler(0xb, 0xffbee788,
0xffbee4d0, 0xff23c008)
4685/1:           -> libgst:oldspace_sigsegv_handler(0xea9aa010, 0x0,
0x0, 0x0)
4685/1:             -> libgst:_gst_mem_protect(0xea9aa000, 0x2000, 0x3,
0x0)
4685/1: mprotect(0xEA9AA000, 8192, PROT_READ|PROT_WRITE) = 0
4685/1:             <- libgst:_gst_mem_protect() = 0
4685/1:             -> libgst:xmalloc(0x10, 0x2000, 0x3, 0x0)
4685/1:             <- libgst:xmalloc() = 0x379a50
4685/1:           <- libgst:oldspace_sigsegv_handler() = 1
4685/1:         <- libsigsegv:sigsegv_handler() = 11
4685/1: setcontext(0xFFBEE4D0)
4685/1:       <- libgst:_gst_mem_alloc() = 0xea9aa9d8
4685/1:     <- libgst:_gst_tenure_oop() = 0xfac1c198
4685/1:     -> libgst:_gst_tenure_oop(0xfac1c028, 0x0, 0x0, 0x0)

Is this expected?  I had 34 of these in my run over the course
of ~5 minutes before the processed alarmed() and died.

Just thought I'd ask to ensure this was 'ok'.

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

> Just thought I'd ask to ensure this was 'ok'.

Yes, it's from the generational garbage collector.

Paolo

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

Is that: http://www.gnu.org/software/smalltalk/manual/html_node/GC.html#GC
up to date?

I have a little bit difficulty to fully understand how
it work.
Especially I don't see how the memory is with all the
space(new, fro, to , fixed) and the generation.

Is there some
figure?

Thanks

-- Mathieu



----- Message d'origine ----
De : Paolo Bonzini <[hidden email]>
À : [hidden email]
Cc : [hidden email]
Envoyé le : Ven 28 mai 2010, 9h 01min 02s
Objet : Re: [Help-smalltalk] Is this normal (caught segv during mem_alloc)?

> Just thought I'd ask to ensure this was 'ok'.

Yes, it's from the generational garbage collector.

Paolo

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





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

Can you tell why there is SIGSEGV.
I mean why would gst somewhere access a bad memory address which mean that there is no more space left?

I guess that is the allocator who make a bad access.

Thanks

        Mth




On May 28, 2010, at 9:01 AM, Paolo Bonzini wrote:


       

       
               
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

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

On 05/28/2010 09:19 PM, Mathieu Suen wrote:
> Can you tell why there is SIGSEGV. I mean why would gst somewhere
> access a bad memory address which mean that there is no more space
> left?

GST protects from writes oldspace pages so that it can learn (from the
segv) when an oldspace page is modified.

Paolo

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