[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3

[Mattias Ellert]

This is a multi-part message in MIME format.
--------------030805030401080700080009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Onizuka wrote:
> Yesterday I downloaded the current snapshot (to solve OS X compilation 
> errors in 1.0.13) and built it.
> I also compiled and installed the latest libusb (0.1.8).
> When I try the scanimage command the scanner make some strange noise 
> =:-/ and then the program hangs... It seems like a problem with Canon 
> scanners I once read in this ML but that was long ago and I think it was 
> solved...
> 
> Anyone can help me?
> Thank You!!!
> 
> Gianfranco
> 
> XS206:~ onizuka$ scanimage > test.pnm
> [plustek] reader_process: finished reading data

Hi!

I have been looking into this issue last weekend. A backtrace shows that 
the process hangs on the read call in sane_read in the plustek backend:

(gdb) backtrace
#0  0x9000ebc4 in read ()
#1  0x005ba994 in sane_plustek_read (handle=0x22e000, data=0xbfff77d0 
"\210\213?", '?' <repeats 197 times>..., max_length=32768, 
length=0xbffff810) at plustek.c:2051
#2  0x000044e0 in scan_it () at scanimage.c:1144
#3  0x00005fd8 in main (argc=1, argv=0xa000104c) at scanimage.c:1990

The problem is the following:

When the reader process is started with fork (like on linux), the file 
descriptors in the reader process are automatically closed when the 
reader process ends.

The read call in the main process then exits because the write end of 
the pipe was closed when the reader process exited.

However, when pthreads are used (like on MacOS X) the file descriptors 
are not closed when the reader thread ends, since in this case the file 
descriptors are shared between the threads.

The read call therefore never exits, since both ends of the pipe are 
still valid file descriptors.

(So this problem is not introduced by the workaround for the broken 
pthread_cancel call on MacOS X, but present on all platforms that uses 
threads.)

It should be possible to fix this by closing the filedescriptors at the 
end of the reader thread, e.g. by applying the following patch. (Has not 
been tested yet, but please do.) If it works it should go into the CVS.

	Mattias


diff -ur sane-backends.orig/backend/plustek.c 
sane-backends/backend/plustek.c
--- sane-backends.orig/backend/plustek.c        2004-01-09 
15:24:30.000000000 +0100
+++ sane-backends/backend/plustek.c     2004-04-05 11:51:43.000000000 +0200
@@ -443,6 +443,8 @@
                 return SANE_STATUS_IO_ERROR;
         }

+       close_pipe( scanner );
+
         DBG( _DBG_PROC, "reader_process: finished reading data\n" );
         return SANE_STATUS_GOOD;
  }


-- 
________________________________________________________________________

mattias.ellert@tsl.uu.se                           tel: +46 18 471 32 58
http://www.tsl.uu.se/~ellert/                      fax: +46 18 471 35 13
________________________________________________________________________

--------------030805030401080700080009
Content-Type: text/plain;
 name="sane-plustek.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sane-plustek.patch"

diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c
--- sane-backends.orig/backend/plustek.c	2004-01-09 15:24:30.000000000 +0100
+++ sane-backends/backend/plustek.c	2004-04-05 11:51:43.000000000 +0200
@@ -443,6 +443,8 @@
 		return SANE_STATUS_IO_ERROR;
 	}
 
+	close_pipe( scanner );
+
 	DBG( _DBG_PROC, "reader_process: finished reading data\n" );
 	return SANE_STATUS_GOOD;
 }

--------------030805030401080700080009--