Description of problem: "wodim --devices" segfaults on my machine. When I go to investigate, the lack of -debuginfo package makes it harder. Exists: http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/wodim-1.1.6-6.fc7.x86_64.rpm Missing: http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/debug/wodim-debuginfo-1.1.6-6.fc7.x86_64.rpm Version-Release number of selected component (if applicable): wodim-1.1.6-6.fc7 How reproducible: all the time on this machine. Steps to Reproduce: 1. wodim --devices Actual results: Segmentation fault Expected results: useful report Additional info: gdb's "where" (without -debuginfo) says: #0 0x0000003602c77180 in strlen () from /lib64/libc.so.6 #1 0x0000003602c460bb in vfprintf () from /lib64/libc.so.6 #2 0x0000003602ce4228 in __vsnprintf_chk () from /lib64/libc.so.6 #3 0x0000003602ce416b in __snprintf_chk () from /lib64/libc.so.6 #4 0x0000000000437680 in list_devices () #5 0x000000000040cef4 in main ()
Oops. Michael Schwendt told me about debuginfo-install http://fedoraproject.org/wiki/StackTraces . Very nice. The debuginfo is in a different RPM: cdrkit-debuginfo. With this debuginfo, here is the traceback: #0 0x0000003602c77180 in strlen () from /lib64/libc.so.6 #1 0x0000003602c460bb in _IO_vfprintf_internal (s=0x7fff2eb3e750, format=<value optimized out>, ap=0x7fff2eb3e8c0) at vfprintf.c:1568 #2 0x0000003602ce4228 in ___vsnprintf_chk (s=0x7fff2eb3f330 " 0 dev='", maxlen=<value optimized out>, flags=1, slen=<value optimized out>, format=0x44be30 "%2d dev='%s'\t%s : '%.8s' '%.16s'\n", args=0x7fff2eb3e8c0) at vsnprintf_chk.c:65 #3 0x0000003602ce416b in ___snprintf_chk (s=0x3600862220 <Address 0x3600862220 out of bounds>, maxlen=7, flags=783542688, slen=0, format=0xfefefefefefefeff <Address 0xfefefefefefefeff out of bounds>) at snprintf_chk.c:36 #4 0x0000000000437680 in list_devices (usalp=0x861010, f=<value optimized out>, pickup_first=0) at /usr/src/debug/cdrkit-1.1.6/wodim/scsi_scan.c:255 #5 0x000000000040cef4 in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/src/debug/cdrkit-1.1.6/wodim/wodim.c:529
still an issue in F8?
The machine in question is still running F7. Is there an update to test for F7? I am willing to build from a source RPM. If I were to install F8 to test, who knows if that would change conditions in such a way as to mask the error.
you may try: http://koji.fedoraproject.org/packages/cdrkit/1.1.6/9.fc9/src/cdrkit-1.1.6-9.fc9.src.rpm
I built from the source RPM mentioned in #4 on my F7 x86_64 system. I only updated to wodim-1.1.6-9.fc7.x86_64.rpm -- no other rpm. I still get the segfault. I didn't learn much more from two minutes with GDB. Optimization makes it hard to correlate lines with object code. When I set a breakpoint on scsi_scan.c:255, gdb said that it sefaulted at that point, without ever hitting the breakpoint. If you cannot get this to fail, I might be able to rebuild without optimization and try again. I don't know how to cleanly and simply suppress -O when using rpmbuild. Is there a nice trick?
I think that I've found the problem (in the stupidest way, but that is another story). In the build, there were a number of compiler diagnostics during the compilation of cdrkit-1.1.6/wodim/scsi_scan.c . They sure look like some #include directives were missing. The segfault is probably caused by taking the result of the call to usal_natname as an int and only passing 32 bits of its value to snprintf (it is actually a char * and thus 64 bits). This probably works (accidentally) on i386. /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c: In function 'open_auto': /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:146: warning: implicit declaration of function 'isspace' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c: In function 'list_devices': /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:229: warning: implicit declaration of function 'usal_fileno' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:255: warning: implicit declaration of function 'usal_natname' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:255: warning: format '%s' expects type 'char *', but argument 7 has type 'int' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:258: warning: format '%s' expects type 'char *', but argument 3 has type 'int' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:279: warning: implicit declaration of function 'free' /home/hugh/rpmbuilds/BUILD/cdrkit-1.1.6/wodim/scsi_scan.c:203: warning: unused variable 'p'
Created attachment 295747 [details] log of rpmbuild of cdrkit-1.1.6-9 This was built on F7 x86_64 from the SRPM mentioned in #4 Note there are serious warnings for the compilation of wodim/scsi_scan.c (described above) libusal/scsi-linux-ata.c libusal/scsi-linux-sg.c libusal/scsitransp.c libhfs_iso/hfs.c genisoimage/genisoimage.c genisoimage/joliet.c genisoimage/multi.c wodim/drv_mmc.c genisoimage/tree.c genisoimage/write.c genisoimage/boot-hppa.c genisoimage/boot-mips.c genisoimage/md5.c genisoimage/jte.c icedax/toc.c There may even be others.
Good catch! :) Ok, here is a new package with all warnings corrected. http://koji.fedoraproject.org/koji/buildinfo?buildID=39792 http://koji.fedoraproject.org/packages/cdrkit/1.1.6/10.fc9/src/cdrkit-1.1.6-10.fc9.src.rpm
Good news: the version announced in #8 does not crash when "wodim --devices" is executed. I really like it that you've got -Wall working. I do have concerns about some of the changes. As a general principal, casts should be avoided if possible: they often paper over problems (suppressing warnings) rather than fixing the actual problem. For example, casting a call to strlen to size_t should not be needed. If it is needed, that strongly suggests that a "#include <string.h>" is missing. I admit that char * vs unsigned char * causes a lot of useless warnings and casting is tempting. Discipline can avoid the problem sometimes but retrofitting that may be hard work. If you don't use the value returned by write(1), you get a warning. The reason ifor this warning is that programs that don't check are likely to misbehave badly when the write returns an error. If you insist on ignoring it, do it transparentlyt: with a cast to void, not an assignment to a variable that is then ignored. Better: check the result and abort if it is unexpected (i.e. not equal to the length parameter). This applies to the other function calls that generate warnings about ignored results. Casting an argument to fprintf so that %d is correct is often the wrong approach. Usually it is more correct to changed the %d to a format for the wider type.
(In reply to comment #9) > Good news: the version announced in #8 does not crash when "wodim --devices" is > executed. > > I really like it that you've got -Wall working. > > I do have concerns about some of the changes. > > As a general principal, casts should be avoided if possible: they often paper > over problems (suppressing warnings) rather than fixing the actual problem. > > For example, casting a call to strlen to size_t should not be needed. If it is > needed, that strongly suggests that a "#include <string.h>" is missing. doh, must have missed this one. > > I admit that char * vs unsigned char * causes a lot of useless warnings and > casting is tempting. Discipline can avoid the problem sometimes but > retrofitting that may be hard work. yep > > If you don't use the value returned by write(1), you get a warning. The reason > ifor this warning is that programs that don't check are likely to misbehave > badly when the write returns an error. If you insist on ignoring it, do it > transparentlyt: with a cast to void, not an assignment to a variable that is > then ignored. Better: check the result and abort if it is unexpected (i.e. not > equal to the length parameter). > > This applies to the other function calls that generate warnings about ignored > results. true... reverted the throwaway changes upstream http://lists.alioth.debian.org/pipermail/debburn-devel/2008-February/thread.html > > Casting an argument to fprintf so that %d is correct is often the wrong > approach. Usually it is more correct to changed the %d to a format for the > wider type. > yep, corrected
http://svn.debian.org/wsvn/debburn/?op=log&rev=0&sc=0&isdir=1
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.