Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
* Thorsten Glaser [2018-12-10 18:18 +0100]: > found 870396 1.1.7-1 > thanks > > Here is an updated debdiff, as usual. It still fixes the segfaults. Why don't you try to push your patches upstream? I won't because you are the author and you know what you did. Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-) signature.asc Description: PGP signature
Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
On Wed, 12 Dec 2018, Elimar Riesebieter wrote: > Why don't you try to push your patches upstream? I won't because you Because I don’t even *know* upstream, let alone have a working relationship with them. > are the author and you know what you did. ☹ bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
Hi Thorsten, * Thorsten Glaser [2017-08-01 18:18 +0200]: > Source: alsa-lib > Version: 1.1.3-5 > Severity: important > Tags: patch > > I was a bit annoyed I could not play any sound on my x32 desktop > any more and today investigated it. It boils down to that amd64 > assembly code was run, which, of course, cannot work. it seems that you are an exclusive user of the x32 port ;-) Please notice [0]. Does it really make sense to maintain code for a handful of users? [0] https://lkml.org/lkml/2018/12/10/1145 Elimar -- .~. /V\ L I N U X /( )\ >Phear the Penguin< ^^-^^ signature.asc Description: PGP signature
Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
(For alsa-de...@alsa-project.org I’ve attached the diffs this
eMail thread has been about, with hope you will apply them in
the next upstream release.)
Elimar Riesebieter dixit:
>it seems that you are an exclusive user of the x32 port ;-) Please
If you actually read that thread you’d know I’m not. (I wrote some
eMails to it, too.)
>Does it really make sense to maintain code for a handful of users?
It’s nothing architecture-specific if I recall, so it will reduce
the chance of problems for all users.
Lemme dissect the patch…
0009-fix-format-strings.patch: fixes, basically, this…
printf("%ld", some_long_long_value);
… which is always an error, on platforms where time_t is larger
than long (which is currently all *64ilp32 platforms (there’s
x32, amd64ilp32, and a third one I forgot, already in existence),
but *will* encompass all ILP32 architectures as we get closer to
the year 2038).
0010-fix-testcase-typo.patch: not actually x32-related, but
noticed during porting.
0011-distinguish-x32-from-amd64.patch: this is the most important
one, and it’s a frigging oneliner:
-#elif defined(__x86_64__)
+#elif defined(__x86_64__) && !defined(__ILP32__)
This one literally only affects x32, indeed (so what I said above
was proven misremembered) but it’s obviously non-harmful to anything
else and easy to carry and forward.
So I’d wish you’d do that as it’s your duty as maintainer of a Debian
package, but alas… I’ll Cc the eMail address you told me and hope
that someone picks it up.
Blessed yuletide,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2# DP: fix long vs. long long confusion when there is a 64-bit time_t
# DP: on a 32-bit long system, such as all newer 32-bit architectures
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2257,11 +2257,11 @@ int snd_pcm_status_dump(snd_pcm_status_t
{
assert(status);
snd_output_printf(out, " state : %s\n",
snd_pcm_state_name((snd_pcm_state_t) status->state));
- snd_output_printf(out, " trigger_time: %ld.%06ld\n",
- status->trigger_tstamp.tv_sec,
- status->trigger_tstamp.tv_nsec / 1000);
- snd_output_printf(out, " tstamp : %ld.%06ld\n",
- status->tstamp.tv_sec, status->tstamp.tv_nsec / 1000);
+ snd_output_printf(out, " trigger_time: %lld.%06ld\n",
+ (long long)status->trigger_tstamp.tv_sec,
+ (long)status->trigger_tstamp.tv_nsec / 1000L);
+ snd_output_printf(out, " tstamp : %lld.%06ld\n",
+ (long long)status->tstamp.tv_sec, (long)status->tstamp.tv_nsec
/ 1000L);
snd_output_printf(out, " delay : %ld\n", (long)status->delay);
snd_output_printf(out, " avail : %ld\n", (long)status->avail);
snd_output_printf(out, " avail_max : %ld\n",
(long)status->avail_max);
--- a/test/latency.c
+++ b/test/latency.c
@@ -325,12 +325,12 @@ void setscheduler(void)
printf("!!!Scheduler set to Round Robin with priority %i FAILED!!!\n",
sched_param.sched_priority);
}
-long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
+long long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
{
- signed long l;
+ signed long long l;
t1.tv_sec -= t2.tv_sec;
- l = (signed long) t1.tv_usec - (signed long) t2.tv_usec;
+ l = (signed long long) t1.tv_usec - (signed long long) t2.tv_usec;
if (l < 0) {
t1.tv_sec--;
l = 100 + l;
@@ -682,10 +682,10 @@ int main(int argc, char *argv[])
snd_pcm_nonblock(phandle, !block ? 1 : 0);
if (ok) {
#if 1
- printf("Playback time = %li.%i, Record time = %li.%i,
diff = %li\n",
- p_tstamp.tv_sec,
+ printf("Playback time = %lli.%i, Record time = %lli.%i,
diff = %lli\n",
+ (long long)p_tstamp.tv_sec,
(int)p_tstamp.tv_usec,
- c_tstamp.tv_sec,
+ (long long)c_tstamp.tv_sec,
(int)c_tstamp.tv_usec,
timediff(p_tstamp, c_tstamp));
#endif
--- a/test/queue_timer.c
+++ b/test/queue_timer.c
@@ -99,11 +99,11 @@ main(int argc ATTRIBUTE_UNUSED, char **a
normalize(&diffdiff);
prevdiff = diff;
- fprintf(stderr, " real time: %12ld sec %8ld usec\nqueue time: %12ld sec
%8ld usec\n diff: %12ld sec %8ld usec\n diffdiff: %12ld sec %8ld usec\n",
- tv.tv_sec, tv.tv_usec,
- (long)rtime->tv_sec, (long)rtime->tv_nsec / 1000,
- diff.tv_sec, diff.tv_usec,
- (long)diffdiff.tv_sec, (long)diffdiff.tv_usec);
+ fprintf(stderr, " rea
Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
Hi Thorsten, * Thorsten Glaser [2017-08-01 18:18 +0200]: > Source: alsa-lib > Version: 1.1.3-5 > Severity: important > Tags: patch > > I was a bit annoyed I could not play any sound on my x32 desktop > any more and today investigated it. It boils down to that amd64 > assembly code was run, which, of course, cannot work. > > While the fix for that (0011-distinguish-x32-from-amd64.patch) > turned out to be a one-liner, I recognised further problems that > appear on all “new” 32-bit architectures added to Linux because > of them using a 64-bit time_t, so 0009-fix-format-strings.patch > was added. > > Finally, I found a minor typo 0010-fix-testcase-typo.patch while > investigating compiler warnings caused by what is fixed by 0009. > > Please apply them all *and* submit them *all* upstream. In the > meantime, I’ve uploaded a package built from the attached debdiff > to unreleased, but that will, of course, unsync M-A, which is not > the desirable thing to have. As I can't evaluate the impact to our officially supported arch's I would prefer to first submit your patches upstream and wait till they be pushed. What do you think? Elimar -- You cannot propel yourself forward by patting yourself on the back.
Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)
Hi, >As I can't evaluate the impact to our officially supported arch's I The impact of 0011-distinguish-x32-from-amd64.patch on any other architecture is absolutely zero, and that’s what fixes x32, so… >and wait till they be pushed. … I’d prefer it very much if you can merge at least that one. The other things are one minor bugfix and a bugfix for an issue that occurs on x32, arm64ilp32, and other architectures, while not breaking on others (as any C programmer can see). Since it only makes debugging output useless it’s probably good enough to wait with them, if you must. >would prefer to first submit your patches upstream By all means, do that anyway. Thanks, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
