R devel - Nov 1999 - memory.profile() messes up the vector heap on Alpha/Linux?

Hello,
I have been trying to debug a problem with R-0.90.0 (this bug was in
0.65.1, too). The following code results in seg faults.  It doesn't
seg-fault on Linux/intel.
> memory.profile()
> gc()
As long as I don't execute memory.profile(), there is no problem with
garbage collection.  So I think that memory.profile() screws up the
heap in some way.

When it seg-faults, it dies in the function compactPhase() in memory.c,

    while (vfrom < R_VTop) {
        s = BACKPOINTER(*vfrom);
        switch (TYPEOF(s)) {    /* get size in bytes */  /* <- dies here */

it segfaults becuase s becomes a pointer to 0x0, when the while loop is
almost finishing, i.e., vfrom is close to R_VTop (vfrom = 0x20001840ef8
and R_VTop = 0x20001841198).

I tried to see what's going on in do_memoryprofile() in memory.c by
stepping with gdb, but I couldn't see what was going wrong (well, to be
honest, I didn't fully understand what was going on).

I thought someone may have some insights about the problem or strategy to
debug this problem.  I wanted to set some kind of watch point, so the 
gdb breaks when the address 0x20001840ef8 is changed.  But I'm not
really good at gdb yet, so I'm wondering if someone can help.

Thanks,
Naoki

platform alpha-unknown-linux
arch     alpha              
os       linux              
system   alpha, linux       
status   Patched            
major    0                  
minor    90.0               
year     1999               
month    November           
day      22                 
language R                  


Naoki Takebayashi     <ntakebay@bio.indiana.edu>
--- Dept. of Biology, Indiana University, Jordan Hall 142
--- 1001 E. Third St. Bloomington, IN 47405-3700 USA

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Naoki Takebayashi <ntakebay@bio.indiana.edu> writes:
> Hello,
> I have been trying to debug a problem with R-0.90.0 (this bug was in
> 0.65.1, too). The following code results in seg faults.  It doesn't
> seg-fault on Linux/intel.
> 
> > memory.profile()
> > gc()
> 
> As long as I don't execute memory.profile(), there is no problem with
> garbage collection.  So I think that memory.profile() screws up the
> heap in some way.
> 
> When it seg-faults, it dies in the function compactPhase() in memory.c,
> 
>     while (vfrom < R_VTop) {
>         s = BACKPOINTER(*vfrom);
>         switch (TYPEOF(s)) {    /* get size in bytes */  /* <- dies here
*/
> 
> it segfaults becuase s becomes a pointer to 0x0, when the while loop is
> almost finishing, i.e., vfrom is close to R_VTop (vfrom = 0x20001840ef8
> and R_VTop = 0x20001841198).
> 
> I tried to see what's going on in do_memoryprofile() in memory.c by
> stepping with gdb, but I couldn't see what was going wrong (well, to be
> honest, I didn't fully understand what was going on).
> 
> I thought someone may have some insights about the problem or strategy to
> debug this problem.  I wanted to set some kind of watch point, so the 
> gdb breaks when the address 0x20001840ef8 is changed.  But I'm not
> really good at gdb yet, so I'm wondering if someone can help.
The gdb command would be 'watch *0x20001840ef8' (it's important to
use
the address as a number so that one gets a hardware watchpoint), but
are you sure that's the right address to watch? I'd try the address of
s itself ('p &s' to print it). Also, what happens if you turn
gctorture() on just before the call to memory.profile? Usually slows
things down horribly, but causes a crash much closer to the actual
damage.

Happy hunting...


-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._