Re: [fluid-dev] Fun dbus crash

[David Henningsson]

On 02/28/2012 10:06 PM, Corbin Simpson wrote:
> Huh. With that argument, about half the time, the test works (I hear
> delightful synthesized piano). I'm getting more fun errors, like:
>
> process 13344: arguments to dbus_pending_call_free_data_slot() were
> incorrect, assertion "*slot_p>= 0" failed in file dbus-pending-call.c
> line 748.
> This is normally a bug in some application using the D-Bus library.

I'm pretty convinced this is a bug in the D-bus library itself, related 
to running two dbus_bus_get_private calls in parallel. Maybe we should 
mutex it just to work around the bug, but I'd rather see the bug being 
fixed in dbus.

> python: malloc.c:2453: sYSMALLOc: Assertion `(old_top == (((mbinptr)
> (((char *)&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
> malloc_chunk, fd))))&&  old_size == 0) || ((unsigned long) (old_size)
> > = (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
> fd_nextsize))+((2 * (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t)))
> - 1)))&&  ((old_top)->size&  0x1)&&  ((unsigned long)old_end&
> pagemask) == 0)' failed.

It's great that they make so self-explanatory error messages, isn't it ;-)

> Can't reproduce under valgrind, which is not a good sign.

:-(

> Anyway, I've gone back over my code and I'm pretty sure I can't
> influence this particular bug much, since it happens inside a call for
> which I don't control *any* parameters (fluid_rtkit_make_realtime) and
> I'm pretty confident that if this were my bug, it would have shown up
> a while ago.
>
> I wish I could somehow debug it further, but at this point I can't do
> it without digging into dbus source, which unsurprisingly is not fun
> enough for me to attempt right now. Maybe later when I have spare
> time.
>
> There really isn't a setting I can flick to tell FS to not attempt rtkit? :c

Sure.

Either avoid RT prio altogether (set the FS option 
audio/midi.realtime-prio to zero, actually, setting midi.realtime-prio 
would be enough I suspect) or allow your current user to get RT prio 
without asking rtkit for it (e g by modifying /etc/security/limits.conf).

// David