[ug-bosug] Bluetooth Stack in userspace

[Moinak Ghosh]

Ananth Shrinivas wrote:
> realfree() is the libc function that coalesces free blocks and maintains 
> them in a splay tree. If your program crashes here,  it means you have 
> written past or before a valid pointer, and modified metadata about 
> allocated blocks that libc maintains.
>
> Makes sense because a redundant malloc() alters the behavior of your 
> program.
>
> Run your program under libumem or watchmalloc - The point of failure 
> will be closer to your root-cause due to the red-zone protection code.
>   

   To add to this the following two links should be useful:

   http://blogs.sun.com/ahl/entry/solaris_10_top_11_20
   http://access1.sun.com/techarticles/libumem.html

Regards,
Moinak.

> Cheers,
> Ananth
>
> Anand Bheemarajaiah wrote:
>   
>> Hello all,
>>
>> I am currently building the bluetooth stack support in solaris for usb bluetooth dongles using the libusb api as a part of my undergraduate final year project.
>>
>> I have completed the hci-usb layer, hci layer, l2cap layer, sdp layer. I am currently doing the rfcomm layer.
>>
>> My query is with the code, it has started to behave in an unpredictable manner,
>>
>> for example,
>>
>> In the main function i am first inquiring for devices, then extracting their human readable names, then connecting to them and going on up the various layers of the bluetooth stack.
>>
>> here in the code, main function looks something like this,
>>
>> .....
>> hci_inquiry(hd,req,resp);  // inquire for devices
>> print_inq(resp);        // extracts the human readable names of devices discovered
>> ....
>>
>>
>> This code started crashing within the print_inq function after some time, now if i embed a malloc in between the two calls it works, 
>>
>> .....
>> hci_inquiry(hd,req,resp);  // inquire for devices
>> malloc(sizeof(struct hci_evt)); 
>> // hci_evt is the structure holding info of incoming event pkts.
>> print_inq(resp);        // extracts the human readable names of devices discovered
>> ....
>>
>>
>> can you tell why it is happening so.... and the runtime error is
>>
>> sigsegv with mapper code ... - it actually shows the callstack to be at realfree.
>>
>> i am sure it is not running out of memory because other commands and memory allocations work just fine.
>>
>> Any help would be great because i believe this is a stupid error and don't want to waste too much time on this.
>>
>> regards,
>> Anand B
>>  
>>  
>> This message posted from opensolaris.org
>> _______________________________________________
>> ug-bosug mailing list
>> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris.org
>> List-Owner: mailto:ug-bosug-owner at opensolaris.org
>> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
>>   
>>     
>
> _______________________________________________
> ug-bosug mailing list
> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris.org
> List-Owner: mailto:ug-bosug-owner at opensolaris.org
> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
>