[alsa-devel] 1.1.4 bug report: dmix fails when using both 32-bit and 64-bit clients
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=c2fbca45102933ddf9ca7...
Cheers, Cheng
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
Takashi
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
Cheers, Cheng
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
Takashi
--- diff --git a/src/pcm/pcm_direct.c b/src/pcm/pcm_direct.c --- a/src/pcm/pcm_direct.c +++ b/src/pcm/pcm_direct.c @@ -136,6 +136,7 @@ retryget: return 1; } else { if (dmix->shmptr->magic != SND_PCM_DIRECT_MAGIC) { + fprintf(stderr, "magic mismatch: shmptr=%x, expected=%x\n", (int)dmix->shmptr->magic, (int)SND_PCM_DIRECT_MAGIC); snd_pcm_direct_shm_discard(dmix); return -EINVAL; }
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
Cheers, Cheng
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
- 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
- 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?
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;
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.
1a9bd0f0448106b917ae7f7bedccfcbf6ce84802The error message is:
ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPCshm 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=c2fbca45102933ddf9ca7...
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.
- 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
- 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=c2fbca45102933ddf9ca7...
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.
- 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
- 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
participants (2)
-
Cheng Sun -
Takashi Iwai