After a recent sane-backends upgrade, my Epson Perfection 2450 Photo USB scanner now segfaults when scanning at high resolution (2400dpi) using either xsane or kooka. When I scan at the same resolution using VueScan, I don't have any problems. Reproducible: Always Steps to Reproduce: 1.Run xsane or run kooka 2.Scan at high resolution 3.Segfault I used gdb, and then valgrind, to try to determine where the problem was. I did a gdb dump of xsane with and without using 'xport G_SLICE=always-malloc', and the results were inconsistent. I then ran both xsane and kooka with valgrind, and got some suspicious consistency. The screen dumps are attached. emerge --info Portage 2.1.6.7 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r8-i686-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-glibc2.0 Timestamp of tree: Wed, 25 Mar 2009 13:45:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.2-r7 dev-util/cmake: 2.4.8 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=prescott -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US" LDFLAGS="-Wl,-O1" LINGUAS="en_US" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/science /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac acl alsa amr amrnb amrwb apache2 berkdb blas bluetooth bzip2 cli cracklib crypt cups curl dbus doc dri dts dv dvd dvdr dvdread encode examples exif ffmpeg flac fortran gcj gd gdbm gif gimp graphviz gstreamer gtk guile hddtemp iconv id3tag ieee1394 imagemagick imlib ipv6 isdnlog jack jadetex java jbig joystick jpeg jpeg2k kde kpathsea ladcca ladspa lcms libsamplerate libv4l2 lm_sensors mad mbox midi mikmod mmx mng motif mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin odbc ogg openal opengl openmp pam pcre pdf perl png posix povray ppds pppd python quicktime raw readline reflection rtc samba scanner sdl session sox spell spl srt sse ssl svg sysfs tcl tcpd theora threads tiff tk truetype unicode usb v4l v4l2 vcd vorbis win32codecs wmf x86 xanim xine xinerama xml xorg xpm xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev vmmouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US" USERLAND="GNU" VIDEO_CARDS="fbdev fglrx intel radeon radeonhd vesa vmware" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 186288 [details] xsane dump with gdb
Created attachment 186289 [details] Glib dump when using export G_SLICE=always-malloc This is what xsane output when I used the G_SLICE export (thinking it might be a g_slice_alloc() issue).
Created attachment 186291 [details] Output of valgrind run of xsane at the crash point
Created attachment 186292 [details] Ouput of valgrind run of Kooka (complete run) This attachment is the complete log of the Kooka valgrind run. Note that the valgrind runs of both xsane and kooka segfault with the "Syscall param ioctl(USBDEVFS_URB).buffer points to unaddressable byte(s)" error, at 0x4000962 in /lib/ld-2.8.so, right after "sanei_usb_read_bulk" and some other identical sane calls.
(In reply to comment #4) With Kooka using qt and xsane using gtk, and both dying in the same fashion at the exact same point while running in the sane_epson2 backend, I think the smoking gun is aimed right at the backend. I see a few other bug reports on bugzilla with the same or almost-the-same sane-backends version/revision, but using different scanner backends, so the problem may actually not be in the epson backend but some common backend code.
(In reply to comment #5) > (In reply to comment #4) > > With Kooka using qt and xsane using gtk, and both dying in the same fashion at > the exact same point while running in the sane_epson2 backend, I think the > smoking gun is aimed right at the backend. I see a few other bug reports on > bugzilla with the same or almost-the-same sane-backends version/revision, but > using different scanner backends, so the problem may actually not be in the > epson backend but some common backend code. > Yes indeed, something seems to be broken there. Can you maybe check if you still get the same problems using sane CVS HEAD? I browsed through their CVS log for a while but I did not see anything obvious. But maybe we are lucky an the issue has already been fixed upstream?
(In reply to comment #6) > > Yes indeed, something seems to be broken there. > Can you maybe check if you still get the same problems using sane CVS HEAD? > I browsed through their CVS log for a while but I did not see anything obvious. > But maybe we are lucky an the issue has already been fixed upstream? > OK, finally got some time to try this. Checked out the latest CVS head from http://www.sane-project.org/cvs.html, made a tarball and a local ebuild with fake higher version, and emerged it. Still no luck. Still get this: ==32171== Syscall param ioctl(USBDEVFS_URB).buffer points to unaddressable byte(s) ==32171== at 0x4000962: (within /lib/ld-2.8.so) ==32171== by 0x40314B1: sanei_usb_read_bulk (in /usr/lib/libsane.so.1.1.0) ==32171== by 0x5812764: e2_recv (in /usr/lib/sane/libsane-epson2.so.1.1.0) ==32171== by 0x580AFA0: sane_epson2_read (in /usr/lib/sane/libsane-epson2.so.1.1.0) ==32171== by 0x403F49E: sane_dll_read (in /usr/lib/libsane.so.1.1.0) ==32171== by 0x402EA3A: sane_read (in /usr/lib/libsane.so.1.1.0) ==32171== by 0x80B29F4: (within /usr/bin/xsane) ==32171== by 0x80B3B05: (within /usr/bin/xsane) ==32171== by 0x80B4911: (within /usr/bin/xsane) ==32171== by 0x80B9155: (within /usr/bin/xsane) ==32171== by 0x47C1DC5: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1800.4) ==32171== by 0x47B5853: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1800.4) ==32171== Address 0x6b5b139 is 0 bytes after a block of size 1 alloc'd ==32171== at 0x4023F5D: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==32171== by 0x402409C: realloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==32171== by 0x580C3F5: sane_epson2_start (in /usr/lib/sane/libsane-epson2.so.1.1.0) ==32171== by 0x403F4E2: sane_dll_start (in /usr/lib/libsane.so.1.1.0) ==32171== by 0x402EA5E: sane_start (in /usr/lib/libsane.so.1.1.0) ==32171== by 0x80B36E0: (within /usr/bin/xsane) ==32171== by 0x80B4911: (within /usr/bin/xsane) ==32171== by 0x80B9155: (within /usr/bin/xsane) ==32171== by 0x47C1DC5: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1800.4) ==32171== by 0x47B5853: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1800.4) ==32171== by 0x47C5D2D: (within /usr/lib/libgobject-2.0.so.0.1800.4) ==32171== by 0x47C7180: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1800.4) --32171-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --32171-- si_code=1; Faulting address: 0x45D8C92E; sp: 0x62756df8 valgrind: the 'impossible' happened: Killed by fatal signal ==32171== at 0x3802F7B6: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x380486F5: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x38001C12: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x38002658: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x380490BA: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x3804A5B4: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0x3805EE06: (within /usr/lib/valgrind/x86-linux/memcheck) ==32171== by 0xFFFFFFFF: ??? ==32171== by 0x380265D8: (within /usr/lib/valgrind/x86-linux/memcheck) I've browsed through the code a bit following the functions listed above. Its use of stack-based buffers 5 levels deep is scary, but I don't see any obvious smoking gun. It's going to require some effort with gdb to track this down. I don't have the time at the moment, but I'll take a closer look at it a bit later.
How is your experience with the .20 release?
(In reply to comment #8) > How is your experience with the .20 release? > Haven't tried that yet. Didn't see it enter the tree. However, I just tried to duplicate the error I was having a few months back before giving the new release a try. I'm still on the x86 stable media-gfx/sane-backends-1.0.19-r2 release. Well, guess what--the problem has gone away. No more segfaults. Same hardware, same scanning resolution, the exact same setup in xsane even. Apparently, something got fixed in the last few months which was the underlying cause of this issue, and it wasn't in the sane-backends code. Perhaps a kernel upgrade of the USB stack, or the recent upgrade to the glib library I saw emerge in recently? Anyway, since I can no longer duplicate the problem, and I don't see anyone else reporting issues, I'm going to change the resolution to 'fixed'.
