Enumerating interfaces hangs in kernel on first boot in safe mode

[mmadia]

As mentioned in 9128#comment:7, NetworkStatus is capable of locking Deskbar when net_server is not running.

While thinking of the various combinations isFirstBoot, isReadOnly, isSafeMode along with what the user may do in those scenarios (e.g., boot CD into safemode and install to a writable device vs. dd anyboot to a USB stick and do a first boot into safemode, as Haiku didn't fully boot in normal mode), the most complete solution I can think of is to modify NetworkStatus to gracefully install itself into Deskbar when net_server is not present.

Perhaps a new network status icon could be made to indicate the lack of net_server? Or would that qualify as kNetworkStatusNoConnection?

[anevilyak]

I've looked into this code and so far I don't really see how it could cause a hang. Nothing it does while installing itself in Deskbar nor in its constructor/AttachedToWindow() in any way talks to net_server (all of it is done via ioctls directly to the network stack at that point), so that doesn't appear to be the reason it's hanging. When it does communicate with net_server later, it uses BMessengers which would fail immediately if net_server isn't actually running. I don't really see any logical reason for it to block like this unless one of the ioctls is itself blocking, which would make it more of a kernel/network stack problem.

[augiedoggie]

backtrace of deskbar window (requested by AnEvilYak)

[anevilyak]

Based on augiedoggie's results in virtualbox (as seen in attachment:bt.png​), the problem does indeed seem to reside in the network stack. Switching component/description.

[augiedoggie]

backtrace of deskbar window right after boot

[augiedoggie]

The first backtrace was after I had attempted to kill the NetworkStatus thread. Uploaded a new one that was taken right after boot although it points to the same area.

[bonefish]

@augiedoggie: Please enter the kernel debugger, get the info for the thread (thread -s <thread ID>), get the info for the mutex it is waiting on (mutex <mutex address>) and a stack trace for the holder of the mutex.

[anevilyak]

Interestingly the mutex seems to have been smashed/corrupted. The only one net_timer acquires is sTimerLock, which is initialized to the name "net timer", which doesn't appear in the mutex info.

[bonefish]

Replying to anevilyak:

Interestingly the mutex seems to have been smashed/corrupted. The only one net_timer acquires is sTimerLock, which is initialized to the name "net timer", which doesn't appear in the mutex info.

The culprit is obviously ​uninit_timers(). It waits for the timer thread only after destroying the mutex, which might still be used by the former.

[augiedoggie]

diff by anevilyak that seems to fix the problem

[anevilyak]

Fixed in hrev44382, thanks for helping track it down augiedoggie!