"Can't obtain network semaphore"

[Till Straumann]

Steve Holle wrote:
> 
>>>
>>> Who would do such a thing?  Or better yet, what do I search on to 
>>> find the culprit?
>>> I don't directly deal with any semaphores in my code.
>>
>>
>> Try setting a breakpoint on rtems_semaphore_delete()
> 
> 
> Once I get through an initial flurry of rtems_semaphore_delete() calls 

Are you sure none of those deletes the network semaphore?

Nothing new to be learned from your stack trace. Next, I recommend
two things:

a) break in _CORE_mutex_Flush() and if 'status' is 4, dump everything
    in 'the_mutex' and make sure it is not the network semaphore.

b) break in rtems_bsdnet_semaphore_obtain when it 'panics' and dump
    the_networkSemaphore, i.e., print all of its fields.

Weird. I can't see any other scenario for a return_code == 4 other
than the semaphore being deleted.

T.


> and the program starts running, when the program crashes and I break 
> again on the rtems_semaphore_delete() call, the "Can't obtain network 
> semaphore" message has already printed out.  My backtrace looks like the 
> following :
>         #14     0x0013a108      in _Thread_Handler () at 
> threadhandler.c:129
>         #13     0x0011df64      in taskEntry () at rtems_glue.c:587
>         #12     0x0011dea0      in networkDaemon () at rtems_glue.c:520
>         #11     0x0011e07e      in rtems_bscnet_event_receive () at 
> rtems_glue.c:642
> The following line is where the error is printed :
>         #10     0x0011dc36      in rtems_bsdnet_semaphore_obtain () at 
> rtems_glue.c:312
>         #9      0x0010f6ca      in rtems_panic () at error.c:211
>         #8      0x0010f66e      in rtems_verror () at error.c:163
>         #7      0x001182c4      in _exit () at newlibc.c:338
>         #6      0x00117fde      in libc_wrapup () at newlibc.c:90
>         #5      0x0013a3b8      in fclose () at fclose.c:80
>         #4      0x0013c932      in __sclose () at stdio.c:119
>         #3      0x0010f366      in _close_r () at close.c:56
>         #2      0x0010f34a      in close () at close.c:36
>         #1      0x00117324      in rtems_libio_free () at libio.c:237
>         #0      rtems_semaphore_delete () at sem.ini:71
> The final line is where I break when the program crashes.  
> _Thread_Executing->Wait.return_code' holds 0 at this point.
> 
> 
> Steve Holle
> Link Communications, Inc.
> 1035 Cerise Rd.
> Billings, MT  59101
> sholle at link-comm.com