| Message ID | s5hshjskdhc.wl-tiwai@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 25 May 2017 at 19:17, Takashi Iwai <tiwai@suse.de> wrote: > On Thu, 25 May 2017 18:51:10 +0200, > Cheng Sun wrote: >> >> On 25 May 2017 at 17:31, Takashi Iwai <tiwai@suse.de> wrote: >> > On Thu, 25 May 2017 17:43:44 +0200, >> > Cheng Sun wrote: >> >> >> >> On 25 May 2017 14:49, "Takashi Iwai" <tiwai@suse.de> wrote: >> >> > >> >> > On Wed, 24 May 2017 21:13:46 +0200, >> >> > Cheng Sun wrote: >> >> > > >> >> > > Hi all, >> >> > > >> >> > > The following commit (released in v1.1.4) introduced an issue where a >> >> > > client compiled against a 32-bit (x86) compile of alsa-lib cannot use >> >> > > the same dmix as a client compiled against a 64-bit alsa-lib. >> >> > > >> >> > > 1a9bd0f0448106b917ae7f7bedccfcbf6ce84802 >> >> > > >> >> > > The error message is: >> >> > > >> >> > > ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC >> >> > > shm instance >> >> > > >> >> > > The following forum post (not mine) describes the symptoms of the >> >> > > issue in more detail (although the git commit the poster specified is >> >> > > not correct): >> >> > > >> >> > > >> >> https://forums.gentoo.org/viewtopic-p-8072290.html?sid=c2fbca45102933ddf9ca7cf8b6713e56 >> >> > >> >> > There is a known problem when you mix up two alsa-lib versions because >> >> > of the changes in dmix shmem struct. The solution should upgrade all >> >> > users. >> >> >> >> (Apologies for duplicate email --accidentally sent the first reply to the >> >> wrong address.) >> >> >> >> Arch Linux has upgraded both its 32 and 64 bit packages to v1.1.4, and I'm >> >> still experiencing this problem. >> >> >> >> While bisecting the bug I linked against two compiles of the same alsa-lib >> >> versions each time. >> >> >> >> Let me know if I can provide any other information. >> > >> > OK, at first to see whether it's the issue of the struct size >> > mismatch, check the following patch. If it is, you'll see the error >> > message. To be sure, check both cases: 64bit -> 32bit, and 32bit -> >> > 64bit. >> >> The behaviour is different for the two cases. >> >> 1) If 64bit client is started first, then the 32bit client prints the following: >> >> magic mismatch: shmptr=a15ad4f0, expected=a15ad4ec >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance >> >> 2) If 32bit client is started first, then the 64bit client only prints: >> >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance >> >> I've added some further print statements and it turns out that this is >> because the "return err;" on line 115 is triggered. > > Hm, so at least the struct size difference is a problem. > Doese the patch below change the behavior? Your patch did not change the behaviour. However, as an experiment I added "__attribute__((__packed__))" to the struct, which fixed the problem. So this does seem to be caused by gcc padding structs differently when compiling 32-bit vs 64-bit. I don't think "__attribute__((__packed__))" is necessarily the correct solution here though. Cheers, Cheng
On Thu, 25 May 2017 20:34:23 +0200, Cheng Sun wrote: > > On 25 May 2017 at 19:17, Takashi Iwai <tiwai@suse.de> wrote: > > On Thu, 25 May 2017 18:51:10 +0200, > > Cheng Sun wrote: > >> > >> On 25 May 2017 at 17:31, Takashi Iwai <tiwai@suse.de> wrote: > >> > On Thu, 25 May 2017 17:43:44 +0200, > >> > Cheng Sun wrote: > >> >> > >> >> On 25 May 2017 14:49, "Takashi Iwai" <tiwai@suse.de> wrote: > >> >> > > >> >> > On Wed, 24 May 2017 21:13:46 +0200, > >> >> > Cheng Sun wrote: > >> >> > > > >> >> > > Hi all, > >> >> > > > >> >> > > The following commit (released in v1.1.4) introduced an issue where a > >> >> > > client compiled against a 32-bit (x86) compile of alsa-lib cannot use > >> >> > > the same dmix as a client compiled against a 64-bit alsa-lib. > >> >> > > > >> >> > > 1a9bd0f0448106b917ae7f7bedccfcbf6ce84802 > >> >> > > > >> >> > > The error message is: > >> >> > > > >> >> > > ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC > >> >> > > shm instance > >> >> > > > >> >> > > The following forum post (not mine) describes the symptoms of the > >> >> > > issue in more detail (although the git commit the poster specified is > >> >> > > not correct): > >> >> > > > >> >> > > > >> >> https://forums.gentoo.org/viewtopic-p-8072290.html?sid=c2fbca45102933ddf9ca7cf8b6713e56 > >> >> > > >> >> > There is a known problem when you mix up two alsa-lib versions because > >> >> > of the changes in dmix shmem struct. The solution should upgrade all > >> >> > users. > >> >> > >> >> (Apologies for duplicate email --accidentally sent the first reply to the > >> >> wrong address.) > >> >> > >> >> Arch Linux has upgraded both its 32 and 64 bit packages to v1.1.4, and I'm > >> >> still experiencing this problem. > >> >> > >> >> While bisecting the bug I linked against two compiles of the same alsa-lib > >> >> versions each time. > >> >> > >> >> Let me know if I can provide any other information. > >> > > >> > OK, at first to see whether it's the issue of the struct size > >> > mismatch, check the following patch. If it is, you'll see the error > >> > message. To be sure, check both cases: 64bit -> 32bit, and 32bit -> > >> > 64bit. > >> > >> The behaviour is different for the two cases. > >> > >> 1) If 64bit client is started first, then the 32bit client prints the following: > >> > >> magic mismatch: shmptr=a15ad4f0, expected=a15ad4ec > >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance > >> > >> 2) If 32bit client is started first, then the 64bit client only prints: > >> > >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance > >> > >> I've added some further print statements and it turns out that this is > >> because the "return err;" on line 115 is triggered. > > > > Hm, so at least the struct size difference is a problem. > > Doese the patch below change the behavior? > > Your patch did not change the behaviour. Hmm, then it's 8 bytes alignment. > However, as an experiment I added "__attribute__((__packed__))" to the > struct, which fixed the problem. So this does seem to be caused by gcc > padding structs differently when compiling 32-bit vs 64-bit. > > I don't think "__attribute__((__packed__))" is necessarily the correct > solution here though. OK, that's at least one way to fix. Another way would be to put another 4 bytes integer as a padding. Could you give it a try, too? Takashi
diff --git a/src/pcm/pcm_direct.h b/src/pcm/pcm_direct.h --- a/src/pcm/pcm_direct.h +++ b/src/pcm/pcm_direct.h @@ -66,7 +66,6 @@ typedef struct { char socket_name[256]; /* name of communication socket */ snd_pcm_type_t type; /* PCM type (currently only hw) */ int use_server; - unsigned int recoveries; /* no of executed recoveries on slave*/ struct { unsigned int format; snd_interval_t rate; @@ -113,6 +112,7 @@ typedef struct { unsigned long long chn_mask; } dshare; } u; + unsigned int recoveries; /* no of executed recoveries on slave*/ } snd_pcm_direct_share_t; typedef struct snd_pcm_direct snd_pcm_direct_t;