Hi,
> - sanetwain should not call sane_cancel() when sane_open()
> hasn't succeeded. That should be fixed by the sanetwain author.
Thanks for localizing that. I was aware that sometimes a cancel call would
trigger a segfault, but haven't had tiem to investigate further. BTW, is it
possible th
Hi all,
thanks to all for helping resolving this. By setting the device name in
sanetwain.ini in c:\windows to the device name returned from scanimage -L
everything now works.
One thing that might help people like myself would be if the location of
sanetwain.ini was explicitly named and this res
[CCed to Herman Kuiper, as this discussion is also about sanetwain]
[Jim George tries to scan with sanetwain but saned always crashes]
Hi,
On Mon, Feb 23, 2004 at 06:57:16PM -, Jim George wrote:
> > So sane_open() wasn't ever called in the gt68xx backend. I even think
> > that sane_open() ret
Hi,
On Mon, Feb 23, 2004 at 09:40:42PM -, Jim George wrote:
> > SANE_DEBUG_DLL=255 SANE_DEBUG_GT68XX=255 saned -d128
> >
> Please find attached.
No, you attached a logfile without gt68xx and dll debugging turned on:
> SANE_DEBUG_SANEI_PA4S2=255 saned -d128
Instead you enabled parallel port
--=_20040223214042_21157
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi,
>
> I don't know. Can you post the complete log including the sane_init
> messages from the gt68xx backend? Maybe even some more debugging:
>
> SANE_DEBUG_DLL=255 SANE_DEBUG_GT68XX=255 sa
Hi,
On Mon, Feb 23, 2004 at 06:57:16PM -, Jim George wrote:
> > I think the scanner was just not detected on the server by saned for
> > some reason (permission problem?).
>
> Why would I be able to access the device happily through saned on the same
> server, but not be able to access the sa
Hi Henning,
> Hi,
>
> On Sun, Feb 22, 2004 at 09:30:47PM +0100, Julien BLACHE wrote:
>> "Jim George" wrote:
>>
>> > [saned] process_request: waiting for request
>> > [saned] process_request: got request 8
>> > [saned] decode_handle: w->status: 0, h: 0, num_handles: 0
>> > [saned] decode_handle: c
Hi,
On Sun, Feb 22, 2004 at 09:30:47PM +0100, Julien BLACHE wrote:
> "Jim George" wrote:
>
> > [saned] process_request: waiting for request
> > [saned] process_request: got request 8
> > [saned] decode_handle: w->status: 0, h: 0, num_handles: 0
> > [saned] decode_handle: cancel: error while deco
"Jim George" wrote:
> [saned] process_request: waiting for request
> [saned] process_request: got request 8
> [saned] decode_handle: w->status: 0, h: 0, num_handles: 0
> [saned] decode_handle: cancel: error while decoding handle argument (h=0,
> Success)
Ok, now that is interesting. How can num
Hi Julien and all,
> Jim, could you try with just
>
> DBG (DBG_ERR, "decode_handle: w->status: %d, h: %d, num_handles: %d\n",
> w->status, h, num_handles);
>
> This way we should get an idea of what's going on...
>
[saned] decode_handle: cancel: error while decoding handle argument (h=0,
Succ
Henning Meier-Geinitz wrote:
>> [saned] process_request: got request 8
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x08049d3e in decode_handle (w=0x8053460, op=0x804f370 "cancel") at
>> saned.c:460
>> 460 DBG (DBG_ERR, "decode_handle: w->status: %d, h: %d, num_handles:
Hi,
On Sun, Feb 22, 2004 at 07:18:08PM -, Jim George wrote:
> Did you see my note to Henning about the debug output from the gt68xx
> backend? It showed 'local_only = true' just before failing, when accessed
> remotely. Is this relevant?
No, that's ok. It just means that the gt68xx backend
Hi Julien and all,
>
> Jim, is the error 100% reproducible ? If yes, could you add the
> following lines in saned.c, decode_handle(), between lines 459 and 460?
>
Yes the error is 100% reproducible when saned is access from a remote host
(it works fine when saned is accessed locally).
Did you see
Henning Meier-Geinitz wrote:
> sane_cancel (handle[h].handle);
>
> That's called with h = -1. Either that causes a segfault or the call
> to sane_cancle of the gt68xx backend with some random handle causes
> the segfault.
>
> I guess saned should check for -1 here before calling sane_cancel.
Hi all,
Although I answered Julien's request for running saned in gdb I also
followed your instructions and got the following.
>> SANE_DEBUG_SANEI_PAS4S2=255 saned -d128
>
Oops :)
> If you ant to get debug output from the backend, use
> SANE_DEBUG_GT68XX. SANE_DEBUG_SANEI_PA4S2 is for Mustek par
Henning Meier-Geinitz wrote:
Hi,
> Now again in the main part of saned:
>
> sane_cancel (handle[h].handle);
>
> That's called with h = -1. Either that causes a segfault or the call
> to sane_cancle of the gt68xx backend with some random handle causes
> the segfault.
It segfaults right away
Hi Julien and all,
I didn't need to rebuild, thankfully, please see below for the result.
>
> gdb /usr/sbin/saned
>> run -d128
> [wait until it crashes]
>> bt
> [copy this output]
#0 0x0804bb5e in process_request (w=0x80533e0) at saned.c:2003
#1 0x0804bcd2 in main (argc=2, argv=0xb5d4) at s
Hi,
On Sat, Feb 21, 2004 at 11:40:09PM -, Jim George wrote:
> The system works well directly and through saned, however it fails when
> accessing saned remotely. I have attached the output of the following
> command to see if this gives anyone any clue to help me?
>
> SANE_DEBUG_SANEI_PAS4S2
"Jim George" wrote:
Hi,
> [saned] process_request: access to resource `gt68xx' granted
> [saned] process_request: waiting for request
> [saned] process_request: got request 8
> [saned] decode_handle: cancel: error while decoding handle argument (h=0,
> Success)
> Segmentation fault
Please rebu
--=_20040221234009_25920
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi Folks,
I've got my Boeder Slimscan working nicely under linux with scanimage and
xsane. However, I wish to use it to allow Windows laptops, running
sanetwain by Herman Kuiper, to do remot
20 matches
Mail list logo
