[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

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

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

Re: [BUG] thread/sync.rb memory corruption

From: Hugh Sasse <hgs@...>
Date: 2006-07-06 16:51:51 UTC
List: ruby-core #8153
On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

> On Fri, 7 Jul 2006, Hugh Sasse wrote:
> 
> > On Thu, 6 Jul 2006, URABE Shyouhei wrote:
> > 
> > > Could someone please confirm this can be reproduced on 1.8.5 pre1?
> > 
> > brains hgs 123 %> ./!$
> > ./syncbug.rb
> > ruby 1.8.5 (2006-07-04) [sparc-solaris2.9]
> > 
> > brains hgs 124 %>
> > 
> > That blank line was just me hitting return, after about a second.
> > It exited immediately.  I don't have electric fence to hand.
> 
> if you don't have electric fence you'll need to run for quite a long time to
> see the code begin to leak - pull up top while you're running if you can to
> confirm

Oh!  I see. I was thinking that the gets was to keep the console open
on platforms that needed it, and that it would not exit until it reached
that.
But it's threaded...

brains hgs 141 %> ./syncbug.rb
ruby 1.8.2 (2004-12-25) [sparc-solaris2.9]
^C./syncbug.rb:125:in `gets': Interrupt
        from ./syncbug.rb:125
brains hgs 142 %> vim !$
vim ./syncbug.rb
brains hgs 143 %> ./syncbug.rb
ruby 1.8.5 (2006-07-04) [sparc-solaris2.9]
^C./syncbug.rb:125:in `gets': Interrupt
        from ./syncbug.rb:125
brains hgs 144 %>


I see increases in memory of the order of Megabytes within a couple of
minutes, for both cases..  What else can I look at?

brains hgs 146 %> truss -fci ./syncbug.rb
ruby 1.8.5 (2006-07-04) [sparc-solaris2.9]
^C./syncbug.rb:125:in `gets': Interrupt
        from ./syncbug.rb:125
signals ------------
SIGVTALRM       5961
total:          5961

syscall               seconds   calls  errors
read                     .002      16
write                    .000       1
open                     .000       7
close                    .000      14
brk                      .021     294
stat                     .003      42     30
getuid                   .000       3
fstat                    .000       7
getgid                   .000       3
ioctl                    .000       1
execve                   .000       1
poll                     .247    4060
sigprocmask              .000       4
sigaction                .000      13
sigfillset               .000       1
getcontext               .000       1
setcontext               .513    5961
evsys                    .000       1
evtrapret                .000       1
mmap                     .001      18
munmap                   .001       5
getrlimit                .000       1
memcntl                  .000       4
setitimer                .000       1
llseek                   .000       7
resolvepath              .000       8
stat64                   .000      11      9
fstat64                  .000       3
getrlimit64              .000       1
open64                   .000       7
                     --------  ------   ----
sys totals:              .797   10497     39
usr time:              58.173
elapsed:               61.510
brains hgs 147 %>

and I got 39 errors for just truss -c.

The Process class can't query its size. I can't see how to extract that
from /proc either.
> 
> i'm trying to test on my box now but stable-snapshot won't build for me.  i'm
> getting
> 
>   gcc -I. -I../.. -I../../. -I../.././ext/dl -DHAVE_DLFCN_H -DHAVE_DLOPEN
> -DHAVE_DLCLOSE -DHAVE_DLSYM -DHAVE_DLERROR  -I. -fPIC -g -O2 -fno-defer-pop
> -fno-omit-frame-pointer  -c cfunc.c
>   cfunc.c:46: warning: `struct cfunc_data' declared inside parameter list
>   cfunc.c:46: warning: its scope is only this definition or declaration, which
>   is probably not what you want
>   cfunc.c: In function `dlcfunc_free':
>   cfunc.c:48: dereferencing pointer to incomplete type
>   cfunc.c:49: dereferencing pointer to incomplete type
> 
> 
> while compiling ext/dl
> 
> anyone?

I don't know about that.
> 
> 
> cheers.
> 
> -a

        Hugh

In This Thread