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