Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 6 years ago

Closed 4 years ago

#507 closed defect (fixed)

Kernel assertion fail at phone_deallocp() at generic/src/ipc/ipcrsc.c:223 phone->state == IPC_PHONE_CONNECTING

Reported by: Jan Vesely Owned by: Jakub Jermář
Priority: major Milestone: 0.7.0
Component: helenos/kernel/generic Version: mainline
Keywords: ipc Cc:
Blocker for: Depends on:
See also:


bug in uhci driver caused an ipc storm that produced this:

failed assertion
phone_deallocp() at generic/src/ipc/ipcrsc.c:223

THE=0xbe304000: pe=0 thr=0xbe1a3898 task=0xbe302000 cpu=0xbf283000 as=0x8009c924 magic=0xfacefeed

Change History (5)

comment:1 Changed 6 years ago by Jakub Jermář

The panicking task is waiting for an answer to the IPC_M_CONNECT_ME_TO call and when it gets it, it starts to process it using the conctmeto.c::answer_process() callback. The callback sees the answer has a non-zero retval so it assumes the phone allocated in conctmeto.c::request_preprocess() is still in the IPC_PHONE_CONNECTING state and attempts to deallocate it via phone_dealloc(), which hits the assertion. Note that conctmeto.c::answer_preprocess() should not connect the phone and thus modify its state on a non-zero retval. It would be instrumental to know what state the phone was actually in at the time of the crash. Without this knowledge we can only speculate:

  • The phone state might have been IPC_PHONE_CONNECTED, which would mean that the call was first affirmatively answered with EOK and the retval somehow changed between the conctmeto.c::answer_preprocess() and conctmeto.c:answer_process() callbacks. This also includes the possibility that the call retval might have been corrupted or abruptly changed as a matter of handling some corner cases.
  • The phone might have been in some other possible phone state different from IPC_PHONE_CONNECTING and IPC_PHONE_CONNECTED, which would suggest a logic error in handling of the phone state transitions during the handling of IPC_M_CONNECT_ME_TO.
  • The phone state might have been corrupted due to an unknown kernel memory corruption, which would explain this behaviour.

comment:2 Changed 6 years ago by Jakub Jermář

Status: newaccepted

comment:3 Changed 4 years ago by Martin Decky


comment:4 Changed 4 years ago by Jakub Jermář

Jan Mareš provided a reproducible test case to a problem which seems to be a duplicate of this one:

The problem seems to be that all phones of the panicking task are actually already connected so the IPC_M_CONNECT_ME_TO's request_preprocess() simply returns ELIMIT because it cannot find a free phone. This results in an ipc_backsend_err() handling, which automatically answers the request with the error code. So far so good. It is answer_process() which is not ready to handle this situation as it assumes that a phone _has_ been allocated (and that the answer comes from the actual callee and not the caller itself). answer_process() interprets call->priv as the phoneid, but call->priv is not initialized in this case.

comment:5 Changed 4 years ago by Jakub Jermář

Keywords: ipc added
Resolution: fixed
Status: acceptedclosed

Fixed in mainline,2336.

Note: See TracTickets for help on using tickets.