[kernel] PANIC: Destroying condition variable entry but it's still attached to variable

[diver]

hrev52931 x86_64, running under VMware.

I'm hitting this panic after opening Deskbar->Applications and starting all of them at once.

​https://github.com/haiku/haiku/blob/master/headers/private/kernel/condition_variable.h#L111

[waddlesplash]

Condition variable was introduced in hrev52691 by mmlr.

[waddlesplash]

<mmlr> the condvar thing is a bit of a nuisance
<mmlr> it really is only a debug thing
<mmlr> nothing bad actually happens
<mmlr> but it's a warning for a possible problem that is nice to keep
<waddlesplash> there isn't a 2 line fix?
<mmlr> it just means that the entry needs to be removed in all error cases
<mmlr> so an autodeleter may work for that
<mmlr> but from a performance overhead that's a bit stupid
<mmlr> so moving the addition of the entry further down is the most sensible thing to do
<mmlr> but it's important where it ends up as it must be ensured that it is added before the team becomes externally visible (and may therefore cause the code path to trigger that needs the entry to be there)
<mmlr> and unfortunately it isn't exactly obvious where that is
<waddlesplash> ok. well, whenever you have 10-20 minutes to do this, that's fine
<mmlr> well, the quick fix would be an autodeleter
<mmlr> but the right one is to move it
<mmlr> I've spent some time trying to find the right spot but as I said it's not exactly obvious
<mmlr> and moving it too far would obviously be bad

[SnodBlatter]

I'd just like to say I'm hitting this consistently within about 5 minutes of reaching desktop, sometimes much quicker. Absolutely a blocker for me, Haiku is unusable. Machine specs can be found in #15142.

[mmlr]

That is at least somewhat surprising, considering this can only be hit in case of team creation/image load failures. Those should be rare. If you hit them reliably it would definitely warrant a closer look as to what's going on there. Can you post a backtrace of your KDL so we can figure out which of the error cases is actually hit?

Also these panics are really only debugging helpers and are non fatal. You should therefore be able the just continue out of the KDL.

[SnodBlatter]

Back trace attached (I used sc, hope that's correct??).

I can indeed continue but nothing works afterwards and I end up with an app server crash. I have saved a report and can try to upload if necessary (really difficult to do, plugging in a USB stick hard locks the system every time so I have to find an alternative way..)

EDIT: FTP server to the rescue, app server report also attached!

[waddlesplash]

You don't need to type SC, this happens automatically; and as a result of typing it the KDL message is now hidden. Please take a picture without that.

[waddlesplash]

Memory: 510.99 MiB total, 450.89 MiB used

It seems you are very close to being out of memory. It's odd this happens so soon after boot; usually an idle system after boot uses only 220MB or so.

[mmlr]

Being almost out of memory would make the load failure more likely of course, so that fits. The origin of the trace is somewhat odd, it looks like a ported application (pthread_func) is exiting and tries to run a command through system(), which fails to load all necessary images to actually run. Can you tell what software it is that's doing that? Maybe a crash reporter trying to be run due to an out of memory error?

The app_server crash is also surprising, seeing that it crashes when closing an accelerant it tried to open for a new driver. Usually I would expect this to run exactly once during app_server startup, but I have not checked the code. I suggest opening another bug report for that one.

Not enough memory is probably the root cause of both issues here. The application and app_server would at least have failed in either case, the KDL here is probably just an additional annoyance.

[SnodBlatter]

Running Haikudepot is a sure-fire way of making this happen, but I think this is only because it's the most memory-hungry program I have found so far. Running Netsurf and opening several tabs can also cause this but the system slows to a crawl before actually getting to the KDL, it feels very much like a memory leak and this is just the end result. Is there a way I can pinpoint the program? With this being so easily reproducible I can run any commands you want.

What I find strange is that none of this happened before June, and the machine has had the same 512MB all the time.

[waddlesplash]

Release builds have KDEBUG disabled so this assert will not exist. Moving out of beta2.

[waddlesplash]

Permanently resolved by hrev53945.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone