[alsa-devel] Issues with alsa-lib-1.0.13 built using arm gcc 4.1.1
Hello,
I have written an external io type plugin for an arm based board. While debugging the plugin, I encountered unexpected errors which I doubt are because of gcc optimizations, and after looking up on web it seems that arm-gcc 4.1.1 which we are using has some known bugs due to which alsa-library functions behave unexpectedly. E.g. snd_mask_refine() reportedly behaves differently when it is compiled using different optimization levels, I am facing the same issue where snd_mask_refine() returns unexpected (-EINVAL) and after I modify the code as in src/pcm/mask_inline.h
MASK_INLINE void snd_mask_copy(snd_mask_t *mask, const snd_mask_t *v) { - *mask = *v; + memcpy(mask->bits, v->bits, MASK_SIZE * 4); }
snd_mask_refine() returns 0 which is valid but I get segfaults just after returning from snd_pcm_ioplug_hw_refine().
Is this a known bug and if yes/no then is there any list of known bugs/quirks when using alsa-lib with arm gcc 4.1.1?
I am attaching a log below, pardon for non-alsa flavour of debug messages in the log.
# aplay -D myplug etc/startup.wav AlsaVersion=1.0.13, Opened for Playback ----- INFO (ALSA) : Successfully Registered the IO plugin ALSA-OPENMAX PLUGIN
Playing WAVE 'etc/startup.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Ste reo ####aplay.c set_params calling snd_pcm_hw_params_any ###### snd_pcm_hw_params_any 1 ##### _snd_pcm_hw_params_any 0 ##### _snd_pcm_hw_params_any 2 ##### _snd_pcm_hw_params_any 8 ##### _snd_pcm_hw_params_any 19 _snd_pcm_hw_param_any in hw_is_mask _snd_pcm_hw_param_any in hw_is_mask _snd_pcm_hw_param_any in hw_is_mask _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval _snd_pcm_hw_param_any in hw_is_interval ##### snd_pcm_hw_params_any 1 #####snd_pcm_hw_refine #####snd_pcm_hw_refine calling hw_refine #### snd_pcm_ioplug_hw_refine 1 snd_ext_parm_mask_refine 1 snd_mask_refine 1 snd_ext_parm_mask_refine return val is = 1 snd_ext_parm_mask_refine 1 snd_mask_refine 1 snd_ext_parm_mask_refine return val is = 1 snd_pcm_ioplug_hw_refine 2 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 3 snd_mask_refine 1 snd_mask_refine 1 snd_mask_refine 1 snd_pcm_ioplug_hw_refine 4 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 5 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 5 change is = 1 ##### return val of hw_refine = 1 #####snd_pcm_hw_refine #####snd_pcm_hw_refine calling hw_refine #### snd_pcm_ioplug_hw_refine 1 snd_ext_parm_mask_refine 1 snd_mask_refine 1 snd_ext_parm_mask_refine return val is = 0 snd_ext_parm_mask_refine 1 snd_mask_refine 1 snd_ext_parm_mask_refine return val is = 0 snd_pcm_ioplug_hw_refine 2 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 3 snd_mask_refine 1 snd_pcm_ioplug_hw_refine 4 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 5 snd_ext_parm_interval_refine 1 snd_ext_parm_interval_refine 1 snd_pcm_ioplug_hw_refine 5 change is = 0 ##### return val of hw_refine = 0 Dec 31 16:27:59 kernel: aplay: unhandled page fault (11) at 0x00000022, code 0x0 17 Dec 31 16:27:59 kernel: pgd = c30d8000 Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: Pid: 206, comm: aplay Dec 31 16:27:59 kernel: CPU: 0 Not tainted (2.6.23.14-BROADCOM #1) Dec 31 16:27:59 kernel: PC is at 0x40170770 Dec 31 16:27:59 kernel: LR is at 0x40168210 Dec 31 16:27:59 kernel: pc : [<40170770>] lr : [<40168210>] psr: a0000010 Dec 31 16:27:59 kernel: sp : bee6f698 ip : 401855f8 fp : bee6fb64 Dec 31 16:27:59 kernel: r10: 401852b0 r9 : 00000006 r8 : bee6f894 Dec 31 16:27:59 kernel: r7 : 0001cc64 r6 : 00000022 r5 : 000130fc r4 : bee6f7 04 Dec 31 16:27:59 kernel: r3 : ffffffff r2 : 00000022 r1 : fffffffe r0 : 000000 22 Dec 31 16:27:59 kernel: Flags: NzCv IRQs on FIQs on Mode USER_32 ISA ARM Se gment user Dec 31 16:27:59 kernel: Control: 00e5387f Table: c30d8008 DAC: 00000015 Dec 31 16:27:59 kernel: (__do_user_fault+0x5c/0xa4) Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: (do_page_fault+0x200/0x238) Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: (do_DataAbort+0x3c/0xa0) Dec 31 16:27:59 kernel: (ret_from_exception+0x0/0x10) Dec 31 16:27:59 kernel: Exception stack(0xc31a1fb0 to 0xc31a1ff8) Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: Dec 31 16:27:59 kernel: Segmentation fault Regards, Sandeep.
On Mon, Mar 17, 2008 at 8:06 PM, sandeep lahane sandeep.lahane@gmail.com wrote:
Hello,
I have written an external io type plugin for an arm based board. While debugging the plugin, I encountered unexpected errors which I doubt are because of gcc optimizations, and after looking up on web it seems that arm-gcc 4.1.1 which we are using has some known bugs due to which alsa-library functions behave unexpectedly. E.g. snd_mask_refine() reportedly behaves differently when it is compiled using different optimization levels, I am facing the same issue where snd_mask_refine() returns unexpected (-EINVAL) and after I modify the code as in src/pcm/mask_inline.h
MASK_INLINE void snd_mask_copy(snd_mask_t *mask, const snd_mask_t *v) {
- *mask = *v;
- memcpy(mask->bits, v->bits, MASK_SIZE * 4);
}
snd_mask_refine() returns 0 which is valid but I get segfaults just after returning from snd_pcm_ioplug_hw_refine().
Is this a known bug and if yes/no then is there any list of known bugs/quirks when using alsa-lib with arm gcc 4.1.1?
I am attaching a log below, pardon for non-alsa flavour of debug messages in the log.
Pruning the log in previous email.
It looks like the issue has been resolved by building alsa-lib and alsa-utils at optimization level 0. The snd_hw_refine() returns wrong values at other optimiztion levels so it has to be either patched/modified to nullify -O settings or optimization level 0 has to be used. I had tried out patching the function and then it returns correct value, but alsa-lib segfaults after successfully returning from it. So currently I am going ahead with building them at -O0.
participants (1)
-
sandeep lahane