6:27 p.m.
Martin, Stephen et al,
I don't know anything about 64-bit systems, but shouldn't size_t
really work correctly in the parsesndfile() call?
In any case, this patch apparently works around a real bug. Please
comment.
- Vin
---------- Forwarded message ----------
From: Hans de Graaff <gra...(a)gentoo.org>
Date: May 12, 2:59 am
Subject: file auto-autoloads.el is newer
To: comp.emacs.xemacs
On Fri, 11 May 2007 15:26:21 -0400, Randy Yates wrote:
I just recently upgraded to
"XEmacs 21.4 (patch 20) \"Double Solitaire\" [Lucid]
(x86_64-unknown-linux, Mule) of Thu May 10 2007 on
localhost.localdomain"
Also, by the way, the (load-default-sounds) command is now crashing -
I
had to bypass it temporarily to get xemacs to run all the way through my
init.el file. Any ideas on why this is so?
I see you are using a 64-bit build on Linux. This will crash with
native
audio as soon as a sound is played. With Gentoo we use the following
patch to fix this issue:
Index: linuxplay.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/linuxplay.c,v
retrieving revision 1.13
diff -u -B -r1.13 linuxplay.c
--- src/linuxplay.c 2001/04/12 18:23:58 1.13
+++ src/linuxplay.c 2006/12/22 07:15:06
＠＠ -290,7 +290,8 ＠＠
fmtType ffmt;
int fmt,speed,tracks;
unsigned char *pptr,*optr,*cptr,*sptr;
- int wrtn,rrtn,crtn,prtn;
+ int wrtn,crtn;
+ size_t prtn,rrtn;
unsigned char sndbuf[SNDBUFSZ];
/* We need to read at least the header information before we can
start
＠＠ -338,9 +339,9 ＠＠
device; repeat until all data has been processed */
rrtn = length;
do {
- for (pptr = data; (prtn = parsesndfile((void **)&pptr,(size_t *)
&rrtn,
+ for (pptr = data; (prtn = parsesndfile((void **)&pptr, &rrtn,
(void **)&optr)) > 0; )
- for (cptr = optr; (crtn = sndcnv((void **)&cptr,(size_t *)
&prtn,
+ for (cptr = optr; (crtn = sndcnv((void **)&cptr, &prtn,
(void **)&sptr)) > 0; ) {
for (;;) {
if ((wrtn = write(audio_fd,sptr,crtn)) < 0) {
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:18 p.m.
I'm not familiar with this code, but a 5-minute inspection
suggests the Gentoo folks are doing exactly the right thing.
I suggest we take it.
Unfortunately, this code is hard to test.
Martin
>>>> "Vin" == Vin Shelton
<acs(a)xemacs.org>" <ethersoft(a)gmail.com> writes:
Vin> Martin, Stephen et al,
Vin> I don't know anything about 64-bit systems, but shouldn't size_t
Vin> really work correctly in the parsesndfile() call?
Vin> In any case, this patch apparently works around a real bug. Please
Vin> comment.
Vin> - Vin
Vin> ---------- Forwarded message ----------
Vin> From: Hans de Graaff <gra...(a)gentoo.org>
Vin> Date: May 12, 2:59 am
Vin> Subject: file auto-autoloads.el is newer
Vin> To: comp.emacs.xemacs
Vin> On Fri, 11 May 2007 15:26:21 -0400, Randy Yates wrote:
> I just recently upgraded to
> "XEmacs 21.4 (patch 20) \"Double Solitaire\"
[Lucid]
> (x86_64-unknown-linux, Mule) of Thu May 10 2007 on
> localhost.localdomain"
> Also, by the way, the (load-default-sounds) command is now
crashing - I
> had to bypass it temporarily to get xemacs to run all the way through my
> init.el file. Any ideas on why this is so?
Vin> I see you are using a 64-bit build on Linux. This will crash with
Vin> native
Vin> audio as soon as a sound is played. With Gentoo we use the following
Vin> patch to fix this issue:
Vin> Index: linuxplay.c
Vin> ===================================================================
Vin> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/linuxplay.c,v
Vin> retrieving revision 1.13
Vin> diff -u -B -r1.13 linuxplay.c
Vin> --- src/linuxplay.c 2001/04/12 18:23:58 1.13
Vin> +++ src/linuxplay.c 2006/12/22 07:15:06
Vin> ＠＠ -290,7 +290,8 ＠＠
Vin> fmtType ffmt;
Vin> int fmt,speed,tracks;
Vin> unsigned char *pptr,*optr,*cptr,*sptr;
Vin> - int wrtn,rrtn,crtn,prtn;
Vin> + int wrtn,crtn;
Vin> + size_t prtn,rrtn;
Vin> unsigned char sndbuf[SNDBUFSZ];
Vin> /* We need to read at least the header information before we can
Vin> start
Vin> ＠＠ -338,9 +339,9 ＠＠
Vin> device; repeat until all data has been processed */
Vin> rrtn = length;
Vin> do {
Vin> - for (pptr = data; (prtn = parsesndfile((void **)&pptr,(size_t *)
Vin> &rrtn,
Vin> + for (pptr = data; (prtn = parsesndfile((void **)&pptr, &rrtn,
Vin> (void **)&optr)) > 0; )
Vin> - for (cptr = optr; (crtn = sndcnv((void **)&cptr,(size_t *)
Vin> &prtn,
Vin> + for (cptr = optr; (crtn = sndcnv((void **)&cptr, &prtn,
Vin> (void **)&sptr)) > 0; ) {
Vin> for (;;) {
Vin> if ((wrtn = write(audio_fd,sptr,crtn)) < 0) {
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:08 a.m.
New subject: [A21.5$21.4] Xemacs Unstable on 64-bit Systems
APPROVE 21.5 RECOMMEND 21.4
Thanks Hans!
"Vin Shelton <acs(a)xemacs.org>" <ethersoft(a)gmail.com> writes:
Martin, Stephen et al,
I don't know anything about 64-bit systems, but shouldn't size_t
really work correctly in the parsesndfile() call?
"(size_t) rrtn" would work, by converting to something with the right
size and the same value (assuming it's positive; size_t is always at
least as big as an int), but the original "(size_t *) &rrtn" formula
says "access storage of width sizeof(int) as if it were sizeof(size_t)
wide". IIRC on most 64-bit machines int is still 32 bits, while
size_t is 64 bits. (At least that's true with GCC on AMD64.) So you
get garbage in the other half of the value.
In any case, this patch apparently works around a real bug. Please
comment.
Well, given Martin's modesty, I'm sure unwilling to claim to really
understand the code, but I'm willing to bet future debugging time that
the patch is correct. So ... fire when ready!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6398
days inactive
6399
days old
2 comments
3 participants
participants (3)
-
Martin Buchholz -
Stephen J. Turnbull -
Vin Shelton