ruby-core

So, is it correct to assume that for language constructs that create built-in types like Range, Array, Hash etc that user-defined initialize methods are never called?

[#11549] Re: Proc initialize method not called under certain circumstances — "Berger, Daniel" <Daniel.Berger@...> 2007/06/28

> -----Original Message-----

[#11550] Re: Proc initialize method not called under certain circumstances — MenTaLguY <mental@...> 2007/06/28

On Fri, 29 Jun 2007 06:24:48 +0900, "John Lam (CLR)" <jflam@microsoft.com> wrote:

[#11553] Re: Proc initialize method not called under certain circumstances — "Marcel Molina Jr." <marcel@...> 2007/06/28

On Fri, Jun 29, 2007 at 06:54:49AM +0900, MenTaLguY wrote:

[#11554] Re: Proc initialize method not called under certain circumstances — murphy <murphy@...> 2007/06/28

> ... for language constructs that create

[#11560] Re: Proc initialize method not called under certain circumstances — Yukihiro Matsumoto <matz@...> 2007/06/29

Hi,

[#11548] NilClass, TrueClass, FalseClass special cased for singleton classes? — "John Lam (CLR)" <jflam@...>

If you do:

3 messages 2007/06/28

[#11557] Re: NilClass, TrueClass, FalseClass special cased for singleton classes? — Nobuyoshi Nakada <nobu@...> 2007/06/29

Hi,

[#11559] Re: NilClass, TrueClass, FalseClass special cased for singleton classes? — Joel VanderWerf <vjoel@...> 2007/06/29

John Lam (CLR) wrote:

[#11555] Name of Classes — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <wonado@...>

Moin, moin!

2 messages 2007/06/28

[#11558] Re: Name of Classes — Nobuyoshi Nakada <nobu@...> 2007/06/29

Moin,

[#11556] delete_if with destructive methods in block — Florian Gross <florgro@...>

Hi,

3 messages 2007/06/29

[#11561] Re: [BUG] delete_if with destructive methods in block — Nobuyoshi Nakada <nobu@...> 2007/06/29

Hi,

[#11567] Re: delete_if with destructive methods in block — Florian Gross <florgro@...> 2007/06/30

That fixes it for me. I got no regressions from Rubinius' hash spec

[#11562] Can clear frozen array using initialize() — Florian Gross <florgro@...>

Hi,

2 messages 2007/06/29

[#11563] Re: [BUG] Can clear frozen array using initialize() — Yukihiro Matsumoto <matz@...> 2007/06/30

Hi,

Re: $2000 USD Reward for help fixing Segmentation Fault in GC

From: Brent Roman <brent@...>

Date: 2007-06-08 05:50:12 UTC

List: ruby-core #11427

Per the suggestion of ggarra and Sylvain, I've been running our robotic
lab control
application under valgrind on an x86 laptop rather than our ARM based
CPU board.

I've posted valgrind's stderr output and the suppression file on our FTP
site:

ftp://ftp.mbari.org/pub/brent

the suppression file is rubySuppressions.valgrind
the stderr output is valgrind.trace2

So far, I have not triggered a Segfault with the simulated hardware
currently
available to me.

The unhandled ioctl is expected.  We're locking
a serial port for exclusive access.

Many of the memcheck errors have been suppressed as they
are apparently artifacts of Ruby's conservative
garbarge collector.  However, those below *do* worry me.

Are they innocuous, or do they indicate a real problem?

....

==10837== Invalid write of size 1
==10837==    at 0x401DEAC: memcpy (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10837==    by 0x8062E5E: rb_thread_restore_context (eval.c:7624)
==10837==    by 0x8062CA8: stack_extend (eval.c:7575)
==10837==    by 0x8062CF3: rb_thread_restore_context (eval.c:7592)
==10837==    by 0x8062CA8: stack_extend (eval.c:7575)
==10837==    by 0x8062CF3: rb_thread_restore_context (eval.c:7592)
==10837==    by 0x8062CA8: stack_extend (eval.c:7575)
==10837==    by 0x8062CF3: rb_thread_restore_context (eval.c:7592)
==10837==    by 0x8062CA8: stack_extend (eval.c:7575)
==10837==    by 0x8062CF3: rb_thread_restore_context (eval.c:7592)
==10837==    by 0x8062CA8: stack_extend (eval.c:7575)
==10837==    by 0x8062CF3: rb_thread_restore_context (eval.c:7592)
==10837==  Address 0xBEFE8908 is on thread 1's stack
==10837==

==10837== Invalid write of size 1
==10837==    at 0x401DEAC: memcpy (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10837==    by 0x8062E5E: rb_thread_restore_context (eval.c:7624)
==10837==    by 0x8063D21: rb_thread_schedule (eval.c:7987)
==10837==    by 0x8063E9D: rb_thread_fd_writable (eval.c:8018)
==10837==    by 0x8070835: io_fflush (io.c:256)
==10837==    by 0x8070A70: rb_io_flush (io.c:339)
==10837==    by 0x805ACEE: call_cfunc (eval.c:4288)
==10837==    by 0x805B78F: rb_call0 (eval.c:4423)
==10837==    by 0x805C2CA: rb_call (eval.c:4654)
==10837==    by 0x8055F53: rb_eval (eval.c:2559)
==10837==    by 0x80594C9: rb_yield_0 (eval.c:3650)
==10837==    by 0x80554A1: rb_eval (eval.c:2391)
==10837==  Address 0xBEFE8908 is on thread 1's stack
==10837==

==10837== Invalid write of size 1
==10837==    at 0x401DEAC: memcpy (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10837==    by 0x8062E5E: rb_thread_restore_context (eval.c:7624)
==10837==    by 0x8063D21: rb_thread_schedule (eval.c:7987)
==10837==    by 0x806466B: rb_thread_stop (eval.c:8309)
==10837==    by 0x805ACEE: call_cfunc (eval.c:4288)
==10837==    by 0x805B78F: rb_call0 (eval.c:4423)
==10837==    by 0x805C2CA: rb_call (eval.c:4654)
==10837==    by 0x8055F53: rb_eval (eval.c:2559)
==10837==    by 0x805BDE8: rb_call0 (eval.c:4560)
==10837==    by 0x805C2CA: rb_call (eval.c:4654)
==10837==    by 0x8055F53: rb_eval (eval.c:2559)
==10837==    by 0x805BDE8: rb_call0 (eval.c:4560)
==10837==  Address 0xBEFE8908 is on thread 1's stack
=

-- 
 Brent Roman
 Software Engineer                 Tel: 831 775 1808
 425 Clinton St., Santa Cruz,      California, 95062
 mailto:brent@mbari.org  http://www.mbari.org/~brent

Thread

Prev Next

In This Thread

Prev Next