[ug-bosug] Bluetooth Stack in userspace

[Ananth Shrinivas]

Anand Bheemarajaiah wrote:
> All the code here is written by me. I have referred to other bluetooth stack impl like bluez but nothing has been ported to opensolaris codebase yet.
>
> you will find the project drafts / milestones as i have accomplished here,
>
> http://anand.bheemaraju.googlepages.com/
>
> the rfcomm_draft_2 is the final draft of rfcomm, so is sdp_draft_2 for sdp.
>
> I am trying to setup an obex connection and be able to transfer a file for my project.
>
> So, sdp code is written only upto the point where i can get the rfcomm channel no. of obex object push profile.
>
> But the code is behaving erratically. I tried using libumem, it gives some errors - says there are some memory leaks and prgram crashes when somewhere "free" is called ( although the pointer is a valid one ).  

If libumem says there is a bug, there is a bug unless you can prove 
otherwise ;-)

Since your application aborts, you need to analyze the core dump left 
behind to find out the root cause of the bug. Start with ::umem_verify, 
::umalog and find out the suspicious buffer and do a ::bufctl_audit to 
see what stack traces lead to the allocation. Then look around that code 
and bang head few times against the wall to get started.

> the code is coming upto around 6000 lines and is there an easy way to fix this.
> If i had used this libumem from beginning maybe i could have fixed the errors from the beginning. how do i go about fixing this now.
>   

To lift a line from Lewis Carroll: "Begin at the beginning and go on 
till you come to the end; then stop."

> This may sound stupid but is there some way to increase the memory of the program like java and all take 200 - 300 mb of ram.   

Increasing heap has nothing to do with mis-managing memory. Java has no 
user level MM bugs because of garbage collection.

There are two ways of fixing the problem you got here - You either fix 
it by spending hours of analyzing libumem/watchmalloc output. Or you get 
this flash of divine inspiration that says you allocated a uint32_t 
buffer and wrote 128 bytes into it somewhere.

Others may have better ideas to add ...

Ananth