[MPlayer-advusers] Mplayer SEGV in module: ao2_init

[Stuart Foster]

On 08/01/11 10:53, Clemens Ladisch wrote:
> Reimar Döffinger wrote:
>> On Thu, Jul 28, 2011 at 03:09:12PM +0100, Stuart Foster wrote:
>>> With glibc 2.14 Mplayer is crashing in the ALSA set-up with a segv
>>> (see attached) prior to the segv if run under valgrind a memory
>>> error is reported in dl-close() (valgind report also in attachment).
>>> I can repeat the problem both on my quad core phenom system and also
>>> on a old IBM Thinkpad R51. Other applications linked against ALSA
>>> report the valgrind problem but I am only experiencing crashes with
>>> Mplayer. Please advise.
>>
>> Your ALSA setup continues to use a dlopen handle after it closed it
>> again.
>
> The crash and the valgrind error are from two different places in
> alsa-lib.  In both cases, it looks as if the handles returned by dlopen
> (or some internal dl* data structures) have been corrupted.
>
>> I don't see how this could be MPlayer's fault,
>
> If there were a bug in the dl* calls, it would be inside alsa-lib.
> However, all these calls are straight dlopen-dlsym-dlcose sequences,
> so I am at a loss to explain this with an ALSA bug.
>
> Stuart, is there a reason that you mention glibc 2.14?
> Is this a regression from an earlier glibc?
>
>
> Regards,
> Clemens
> _______________________________________________
> MPlayer-advusers mailing list
> MPlayer-advusers at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-advusers

The same binaries appeared fine at glibc-2.13 and earlier originally the 
only change was moving on to glibc-2.14. The glibc people have assured 
me this is an application issue, any way time will tell.

Since the problem came up I have compiled all the components with 
different compiler options (glibc alsa-lib and mplayer) and on different 
hardware (all 32 bit LFS systems though) and for me the problem is 
consistent. I am currently working through all the various 
dlopen-dlsym-dlcose sequences to see if I can find the problematic piece 
of code.
I currently think the symbol being processed at the time valgrind 
complains is: "snd_config_hook_load_for_all_cards".
I know If I comment out the snd_dlclose on line 3327 of alsa-lib conf.c 
the problem goes away (obviously not the solution as I now have an 
in-balance in the dynamic symbol lookup processing).

Thanks

Stuart