SEGSEGV in libusb 0.1.12 on FreeBSD 6.2

Hi - I'm looking at using Gnokii with a Nokia 6155 phone on FreeBSD 
6.2-PRERELEASE. Gnokii makes use of libusb. I'm getting a seg fault in 
libusb (bsd.c:217):

(gdb) bt
#0  0x281febf9 in usb_claim_interface (dev=0x0, interface=10) at bsd.c:217
#1  0x281cec2a in fbusdku2usb_open (state=0x8066000) at dku2libusb.c:368
#2  0x2819533a in device_open (file=0x8066044 "/dev/ugen0.2",
     with_odd_parity=0, with_async=0, with_hw_handshake=0,
     device_type=GN_CT_Serial, state=0x8066000) at device.c:85
#3  0x281cd08b in phonet_initialise (state=0x8066000) at fbus-phonet.c:86
#4  0x281b9428 in NK6510_Functions (op=GN_OP_Init, data=0x0, 
state=0x8066000)
     at nk6510.c:520
#5  0x28192c92 in register_driver (driver=0x281f16a0, model=0x8066004 
"6100",
     setupmodel=0x0, sm=0x8066000) at gsm-api.c:114
#6  0x28192e26 in gn_gsm_initialise (sm=0x8066000) at gsm-api.c:149
#7  0x28192538 in gn_lib_phone_open (state=0x8066000) at libfunctions.c:136
#8  0x0804a563 in parse_options (argc=2, argv=0xbfbfeae8) at gnokii.c:279
#9  0x0804b139 in main (argc=2, argv=0xbfbfeae8) at gnokii.c:1045

Doing truss on the gnokii process I see the following snippet:

open("/dev/ugen0",O_RDWR,05010001031)            = 4 (0x4)
ioctl(4,USB_SET_TIMEOUT,0xbfbf9bfc)              = 0 (0x0)
ioctl(4,USB_DO_REQUEST,0xbfbf9ba0)               = 0 (0x0)
ioctl(4,USB_SET_TIMEOUT,0xbfbf9bfc)              = 0 (0x0)
ioctl(4,USB_DO_REQUEST,0xbfbf9ba0)               = 0 (0x0)
ioctl(4,USB_SET_TIMEOUT,0xbfbf9bfc)              = 0 (0x0)

Re: SEGSEGV in libusb 0.1.12 on FreeBSD 6.2

On Fri, Jan 05, 2007 at 04:59:08PM +1300, Mark Kirkwood wrote:
> (gdb) bt
> #0  0x281febf9 in usb_claim_interface (dev=0x0, interface=10) at bsd.c:217
> #1  0x281cec2a in fbusdku2usb_open (state=0x8066000) at dku2libusb.c:368
> #2  0x2819533a in device_open (file=0x8066044 "/dev/ugen0.2",
>      with_odd_parity=0, with_async=0, with_hw_handshake=0,
>      device_type=GN_CT_Serial, state=0x8066000) at device.c:85

Could you show us the code around these two points? (device.c:85 and
dku2libusb.c:368)

Which version of gnokii are you using?

//Peter

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: SEGSEGV in libusb 0.1.12 on FreeBSD 6.2

Hi,

On Fri, Jan 05, 2007 at 04:59:08PM +1300, Mark Kirkwood wrote:
> (gdb) bt
> #0  0x281febf9 in usb_claim_interface (dev=0x0, interface=10) at bsd.c:217

int usb_claim_interface(usb_dev_handle *dev, int interface)
{
  /* BSD doesn't have the corresponding ioctl.  It seems to
     be sufficient to open the relevant endpoints as needed. */

  dev->interface = interface;

  return 0;
}

So passing NULL as dev obviously causes a segfault and sounds like a
gnokii bug.

> #1  0x281cec2a in fbusdku2usb_open (state=0x8066000) at dku2libusb.c:368

gnokii 0.6.14 calls usb_claim_interface from
"usbfbus_connect_request", what version of gnokii are you using? Anyways, they

DEVINSTANCE(state)->interface->dev_data = usb_open(DEVINSTANCE(state)->interface->device);

but never check the return value of usb_open and just blindly pass it to

ret = usb_claim_interface(DEVINSTANCE(state)->interface->dev_data, DEVINSTANCE(state)->interface->data_interface);

Re: SEGSEGV in libusb 0.1.12 on FreeBSD 6.2

Timo Juhani Lindfors wrote:

> So passing NULL as dev obviously causes a segfault and sounds like a
> gnokii bug.
> 
> 
>> #1  0x281cec2a in fbusdku2usb_open (state=0x8066000) at dku2libusb.c:368
> 
> gnokii 0.6.14 calls usb_claim_interface from
> "usbfbus_connect_request", what version of gnokii are you using? Anyways, they
> 

Sorry - using 0.6.14...

> DEVINSTANCE(state)->interface->dev_data = usb_open(DEVINSTANCE(state)->interface->device);
> 
> but never check the return value of usb_open and just blindly pass it to
> 
> ret = usb_claim_interface(DEVINSTANCE(state)->interface->dev_data, DEVINSTANCE(state)->interface->data_interface);
> 
> 

Yeah, I'll go back and bug them about it...

Thanks

Mark

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT

Error Number for PIPE Stalled on MacOSX (Darwin)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Error Number for PIPE Stalled on MacOSX (Darwin)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Error Number for PIPE Stalled on MacOSX (Darwin)

Jake,

now the point is, that using libusb there are different return codes  
for this case.
I have trouble porting the application from Linux to Darwin,  since  
the return code is not the same for both platforms.

On Linux it is EPIPE and on Darwin it is LUSBDARWINSTALL. So my error  
handler source (and application) has to be platform dependent,  
switching between different return codes.

Do you know why there are different return codes for this case?

Thanks,
Markus

Am 08.01.2007 um 21:05 schrieb Jake Janovetz:

> Markus-
>
> I've seen this problem recently on Mac OS X (not associated with  
> libusb in my case, but the problem may translate).  We had a device  
> programmed with a wMaxPacketSize of 1024 for a bulk endpoint.  Our  
> Windows boxes didn't seem to take issue with it, but the Mac did.   
> Technically, I don't think it's a legal configuration.
>
> I forget many of the details now, but when I looked into it, I  
> think the kIOUSBPipeStalled error is often associated with poorly  
> configured devices that the Mac host controller didn't like.
>
>    Cheers,
>    Jake
>
>
> From: libusb-devel-bounces <at> lists.sourceforge.net [mailto:libusb- 
> devel-bounces <at> lists.sourceforge.net] On Behalf Of Markus Schneider
> Sent: Sunday, January 07, 2007 11:04 AM
> To: libusb-devel <at> lists.sourceforge.net
> Subject: [Libusb-devel] Error Number for PIPE Stalled on MacOSX  
> (Darwin)
>
> Hello,
>
> I am using a libusb on MacOSX 10.4.8 (Darwin).
>
> My USB device returns kIOUSBPipeStalled in some special case.  
> However libusb is translating this error to LUSBDARWINSTALL.
> Actually, I was expecting to see the EPIPE error returned, instead  
> of LUSBDARWINSTALL.
>
> from darwin.c:
>
> /* not a valid errorno outside darwin.c */
> #define LUSBDARWINSTALL (ELAST+1)
>
> static int darwin_to_errno (int result) {
> switch (result) {
> case kIOReturnSuccess:
> return 0;
> case kIOReturnNotOpen:
> return EBADF;
> case kIOReturnNoDevice:
> case kIOUSBNoAsyncPortErr:
> return ENXIO;
> case kIOReturnExclusiveAccess:
> return EBUSY;
> case kIOUSBPipeStalled:
> return LUSBDARWINSTALL;
> case kIOReturnBadArgument:
> return EINVAL;
> case kIOUSBTransactionTimeout:
> return ETIMEDOUT;
> case kIOReturnError:
> default:
> return 1;
> }
> }
>
> Can somebody please provide some detail about this implementation.
>
>
> Thanks,
> Markus
>
> ---------------------------------------------------------------------- 
> ----------------------------
> Markus Schneider   markus.schneider <at> netic.de
> Pommernweg 31/1   +49-(0)7144-283138
> 74385 Pleidelsheim   +49-(0)179-1277481
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Error Number for PIPE Stalled on MacOSX (Darwin)

On Mon, Jan 08, 2007 at 10:30:24PM +0100, Markus Schneider wrote:
> Do you know why there are different return codes for this case?

I doubt it's by design, but can't tell for sure. I don't know how
much testing the Darwin port has received.

//Peter

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Error Number for PIPE Stalled on MacOSX (Darwin)

Perhaps the libusb error code "space" was insufficient to represent all the
error codes presentable by Darwin.

   Jake

> -----Original Message-----
> From: libusb-devel-bounces <at> lists.sourceforge.net 
> [mailto:libusb-devel-bounces <at> lists.sourceforge.net] On Behalf 
> Of Peter Stuge
> Sent: Monday, January 08, 2007 2:50 PM
> To: libusb-devel <at> lists.sourceforge.net
> Subject: Re: [Libusb-devel] Error Number for PIPE Stalled on 
> MacOSX (Darwin)
> 
> On Mon, Jan 08, 2007 at 10:30:24PM +0100, Markus Schneider wrote:
> > Do you know why there are different return codes for this case?
> 
> I doubt it's by design, but can't tell for sure. I don't know 
> how much testing the Darwin port has received.
> 
> 
> //Peter

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Error Number for PIPE Stalled on MacOSX (Darwin)

Peter,

it seems though, that it is on purpose, because the code value 103 is  
outside of the range of (darwin-) errno.h.

Since PipeStalled is can occur, I think there  should be a valid code  
returned on darwin.

--
Markus

Am 08.01.2007 um 23:49 schrieb Peter Stuge:

> On Mon, Jan 08, 2007 at 10:30:24PM +0100, Markus Schneider wrote:
>> Do you know why there are different return codes for this case?
>
> I doubt it's by design, but can't tell for sure. I don't know how
> much testing the Darwin port has received.
>
>
> //Peter
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV