jack crashes client if v mem exhausted - mmap() failure

[jackaudio]

jack crashes client if v mem exhausted - mmap() failure

[sletz]

Please give a patch, or a git branch access.

Stéphane

Le 7 janv. 2015 à 14:43, AlexandruCostache [email protected] a écrit :

If the client uses up almost all of its virtual memory jack may crash it in common/JackShmMem.h:

The destructor for JackShmReadWritePtr is called although Init() failed and it will call GetShmAddress()->UnlockMemory();

The fastest sollution that solved my issue was to add another flag member, initDone and set it to TRUE in Init() right after locking memory so that GetShmAddress()->UnlockMemory() doesn't do an illegal access.

I'm not familiar with jackd so I'm asking: is this approach acceptable/safe or is there a better way to handle this mmap() failure?

—
Reply to this email directly or view it on GitHub.

[acostach]

Sure, here it is: https://www.dropbox.com/s/5qv5dr938c54d8q/0001-Avoid-crashing-client-when-mmap-fails.patch?dl=0

[sletz]

Le 7 janv. 2015 à 14:43, AlexandruCostache [email protected] a écrit :

If the client uses up almost all of its virtual memory jack may crash it in common/JackShmMem.h:

1. Does "Init" really crash or does it call " throw std::bad_alloc();" ?

2. or does it crash in GetShmAddress()->LockMemory() ?

The destructor for JackShmReadWritePtr is called although Init() failed and it will call GetShmAddress()->UnlockMemory();

The fastest sollution that solved my issue was to add another flag member, initDone and set it to TRUE in Init() right after locking memory so that GetShmAddress()->UnlockMemory() doesn't do an illegal access.

I'm not familiar with jackd so I'm asking: is this approach acceptable/safe or is there a better way to handle this mmap() failure?

Stéphane=

[acostach]

Crashes in destructor, ~JackShmReadWritePtr(), to be more specific in GetShmAddress()->UnlockMemory()

[acostach]

GetShmAddress() does not yeld a valid address because Init() failed previously. If JackShmReadWritePtr in not used for iterators then that patch should do just fine.

[sletz]

No the question is : how the call to Init fails in the first place? where in the code of Init does it fails ? (calling throw std::bad_alloc(), or chasing in GetShmAddress()->LockMemory();)

Thanks

Stéphane

Le 7 janv. 2015 à 15:24, AlexandruCostache [email protected] a écrit :

Crashes in destructor, ~JackShmReadWritePtr(), to be more specific in GetShmAddress()->UnlockMemory()

—
Reply to this email directly or view it on GitHub.

[acostach]

It failed trough bad_alloc

[sletz]

Could you possibly try the bit more general patch here :

Stéphane

Le 7 janv. 2015 à 15:34, AlexandruCostache [email protected] a écrit :

It failed trough bad_alloc

—
Reply to this email directly or view it on GitHub.

[acostach]

I'm not seeing the patch, looks like the link doesn't appear. Can you please post it again?

[sletz]

Give me your direct mail address.

Stéphane

Le 7 janv. 2015 à 15:54, AlexandruCostache [email protected] a écrit :

I'm not seeing the patch, looks like the link doesn't appear

—
Reply to this email directly or view it on GitHub.

[acostach]

It's the one in the patch I've provided. Not posting it here due to spamming considerations. Thanks

[acostach]

Took it for a spin and it behaves ok - the same.

[sletz]

Thanks commited and pushed on go.

Stéphane

Le 7 janv. 2015 à 16:51, AlexandruCostache [email protected] a écrit :

Took it for a spin and it behaves ok

—
Reply to this email directly or view it on GitHub.

[acostach]

Thank you!