[VCDImager Bugs/Devel] None

[R. Bernstein]

Will Dormann writes:
 > Starting program:
 > /home/will/vcdimager-0.7.13/frontends/cli/vcddump
 > -------------------------------------------------------------------------------
 > vcddump - GNU VCDImager - (Super) Video CD Report
 > $Id: vcddump.c,v 1.8 2003/01/30 16:55:58 rocky Exp $
 > 
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > 0x0804e70d in vcdinfo_open (obj=0xbfffdad0,
 > source_name=0x0,
 >     source_type=VCDINFO_SOURCE_UNDEF) at
 > vcdinfo.c:2012
 > 2012        size_t len = strlen(source_name)+1;
 > (gdb)

This is very odd. It's as if vcddebug is following code or been
compiled incorrectly. I just checked against the vcdimager-0.7.13
sources on alpha.gnu.org. The first thing that is weird is that
vcddump should never pass a source_type equal to VCDINFO_SOURCE_UNDEF.

There is this on line 1090 of vcddump:
  if (VCDINFO_SOURCE_UNDEF==gl.source_type) 
    {
      gl.source_type = VCDINFO_SOURCE_DEVICE;
    }

  open_rc = vcdinfo_open(&obj, image_fname, gl.source_type);

If however you were to call VCDINFO_SOURCE_UNDEF you should have
gotten an error return. 

Next, if you've gotten to line 2012 in vcdinfo, then you've already
successfully opened the thing you are reading from and furthermore
have read from it at line 1986 of vcdinfo:

  if (vcd_image_source_read_mode2_sector (obj->img, &(obj->pvd), 
                                          ISO_PVD_SECTOR, false))
    return(false);

So source_name should have been set. Best guess right now is that 
memory has been clobbered. 

To track this down further, to set a breakpoint at that line 1090 of
vcddump and see how it is getting into vcddump with those values (if
it in fact it initially is). And then how we came to do a couple of
read *successfully* having source_name set -- it probably was.