[9fans] Zombie-fds

[9fans] Zombie-fds

[Sascha Retzki]

Hi again,

alongside with ls-dj and the joy APE is, I have noticed fclose() must be broken somehow, or I don't see what is wrong.


The issue is that ls-dj opens the ogg-files when it puts them into the playlist (parsing the vorbis-comment, see if it actually is an OGG, etc), that is a fopen(), some calls to libvorbis, then fclose(). I noticed ls-dj cannot put more than ~90 files into the playlist, all further oggs fail with 'Error 0'. 

A quick cat /proc/?/fd | wc -l will show a problem: Apperently, the files are not closed again (I am pretty sure procfs/?/fd just shows opened FDs, right?)


Known issue? Unknown issue? Anything I can do? :)


Mfg, Sascha

Re: [9fans] Zombie-fds

[erik quanstrom]

the APE code looks correct.  the fd is closed unless the state is already CLOSED or 
the STRING flag is set.  the STRING flag is only set by sprint and sscan.  what stdio
functions are called for each playlist item?

- erik

Re: [9fans] Zombie-fds

[Sascha Retzki]

> the APE code looks correct.  the fd is closed unless the state is already CLOSED or 
> the STRING flag is set.  the STRING flag is only set by sprint and sscan.  what stdio
> functions are called for each playlist item?
> 

This is isogg(), called for each playlist item in the 'adding-phase'. The error-string is "Error 0", cd /proc/1075/fd ; cat fd | wc -l -> 91.


int
isogg(char *file)
{
	OggVorbis_File vf;
	FILE *fd;

	if((fd = fopen(file,"r")) == NULL) {
		printf("Could not open %s: %s\n",file,strerror(errno));
		return Error;
	}

	if(ov_open(fd, &vf, NULL, 0) < 0) {
		printf("ERROR: Failed to open input as vorbis\n");
		fclose(fd);
		return Error;
	}

	fclose(fd);
	ov_clear(&vf);
	return Success;
}


I just noticed something else. It must be related to the way I fork. I use the child to open /dev/audio and play the vorbis-file, the other one does the user-interfacing etc.The child fills up his fd-file, too. A nice history of what I have played so far, it is a

rfork(RFMEM | RFPROC | RFNAMEG)

I use RFMEM because I use a modulglobally defined linked list as a playlist, and play() (playvorbis(), etc) need to know the up-to-date playlist. 

Anyway, I don't see how RFMEM could actually cause this, but it is just something... "mythical" and honestly the only thing I see, by far, which could cause any unexpected behaviour.


Thanks, Sascha

> - erik

Re: [9fans] Zombie-fds

[erik quanstrom]

what does ov_open do to the FILE*? (it's pretty confusing to call a FILE* "fd", btw.)

why don't you breadcrumb the spaces between fopen/ov_open and ov_open/fclose?
e,g.
	fprint(2, "f->flags = %x; f->fd = %d\n", fp->flags, fp->fd);

a better way to accompish "isogg" might be to teach file(1) to recognize ogg files.

- erik

Re: [9fans] Zombie-fds

[Russ Cox]

The problem is that you are missing an fclose in plsadd (not isogg).
Also, ov_close will fclose the file you passed to ov_open,
so you don't actually need both fclose and ov_clear in isogg.
But plsadd has neither.

Russ

Re: [9fans] Zombie-fds

[Sascha Retzki]

> what does ov_open do to the FILE*? (it's pretty confusing to call a FILE* "fd", btw.)

Heh, now that confuses me. A File Deskriptor is a number describing a file, I never made any differences between an int fd and a FILE *fd.  

> 
> why don't you breadcrumb the spaces between fopen/ov_open and ov_open/fclose?
> e,g.
> 	fprint(2, "f->flags = %x; f->fd = %d\n", fp->flags, fp->fd);

What is fp? :-)

> 
> a better way to accompish "isogg" might be to teach file(1) to recognize ogg files.

Actually a good point. Despite I have no idea how file(1) works, I know the word 'magic', I guess it reads some bytes of the file and compares it to entries in some kind of database. The canonical OGG-format has the strings 'ogg ' and 'vorbis' in it, iirc, maybe I give that a shot.

Anyway, as the problem seems to occur with my playvorbis() (also using libvorbis-functions, btw...), too, it does not fix the issue.

You stay correct, tho. Maybe libvorbis does something strange to the FILE *, or, as mentioned in the earlier posts, does use sscanf() or similar.

> 
> - erik

Re: [9fans] Zombie-fds

[Sascha Retzki]

> The problem is that you are missing an fclose in plsadd (not isogg).
> Also, ov_close will fclose the file you passed to ov_open,
> so you don't actually need both fclose and ov_clear in isogg.
> But plsadd has neither.
> 

Ouch!!

Thank you, Russ, again, for the help. That was the problem.

However I could miss that one. :)


Have a nice weekend Russ, Erik, and thanks for your time.

> Russ

Re: [9fans] Zombie-fds

[erik quanstrom]

On Fri Sep 15 08:07:39 CDT 2006, sretzki@gmx.de wrote:
> What is fp? :-)

it's psudo-hungarian for file pointer.  annoying, but standard.
quite in keeping with stdio. ;-)

> 
> > 
> > a better way to accompish "isogg" might be to teach file(1) to recognize ogg files.
> 
> Actually a good point. Despite I have no idea how file(1) works, I know the word 'magic', I guess it reads some bytes of the file and compares it to entries in some kind of database. The canonical OGG-format has the strings 'ogg ' and 'vorbis' in it, iirc, maybe I give that a shot.

maybe i'll work on that when i get frustrated with getting the cursor working
on this integrated geforce 6150 (nForce4).  the magic file from linux is generally a good place 
to steal bits.

> 
> Anyway, as the problem seems to occur with my playvorbis() (also using libvorbis-functions, btw...), too, it does not fix the issue.
> 
> You stay correct, tho. Maybe libvorbis does something strange to the FILE *, or, as mentioned in the earlier posts, does use sscanf() or similar.

sscanf shouldn't be a problem.  getting personal with the elements of the FILE* might
be.

- erik