[Gc] Interior pointers

Bruce Hoult bruce at hoult.org
Fri Dec 28 03:52:47 PST 2012


Interior pointers aren't an issue. buf stays live, so the GC will
trace from that, and anyway there are no allocations in the loop to
cause a GC.

But there are lots of things here not defined. Please give complete
code examples so we don't have to guess.

Offhand, the most likely thing to me is allnames being allocated
justbefore but and overflowing, overwriting buf.


On Sat, Dec 29, 2012 at 12:13 AM, Michael Talbot-Wilson <mtw at view.net.au> wrote:
>
> What I'm trying to do is create an array of the names in a directoy
> using a modification of the Linux getdents(2) example program.  I'm
> assigning the address of a struct linux_dirent plus the offset to the
> d_name in it to a char** element.  It works for small directories but
> fails at about the 2700th directory entry, at which point the array is
> overwritten, back to element [0].
>
> Am I doing something illegal or ignorant with code like
>
>   for (;;) {
>     buf = (char *) GC_MALLOC(BUF_SIZE);
>     nread = syscall(SYS_getdents, fd, buf, BUF_SIZE);
>     if (nread==0)
>       break;
>
>     for (bpos=0; bpos<nread;) {
>       d = (struct linux_dirent *) (buf+bpos);
>       d_type = *(buf + bpos + d->d_reclen - 1);
>       allnames[array_subscript++] = (char *)d + off_to_name;
>       printf("& allnames[0]=%ld\n", (long) &(allnames[0]));
>       printf("1 allnames[0]=%s\n", allnames[0]);
>       printf("2 allnames[%d]=%s\n",
>              array_subscript-1, allnames[array_subscript-1]);
>       bpos+=d->d_reclen;
>     }
>   }
>
> ?
>
> Producing (where "." was the first name read):
>
> & allnames[0]=134897680
> 1 allnames[0]=.
> 2 allnames[2728]=bzcat
> & allnames[0]=134897680
> 1 allnames[0]=.
> 2 allnames[2729]=xfce4-panel
> & allnames[0]=134897680
> 1 allnames[0]=^L^H
> 2 allnames[2730]=unhex
> & allnames[0]=134897680
> 1 allnames[0]=^L^H:<83>^L^H^B
> 2 allnames[2731]=sgmlcheck
> & allnames[0]=134897680
> 1 allnames[0]=^L^H:<83>^L^HR<83>^L^H<B3>^C
> 2 allnames[2732]=svnversion
>
> with endless increase in the length of the garbage.
>
> Hope someone can tell me what I'm doing wrong.
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/


More information about the Gc mailing list