From xemacs-m  Mon Apr 14 03:32:19 1997
Received: from elvenbow.nc.kyushu-u.ac.jp (elvenbow.nc.kyushu-u.ac.jp [133.5.6.4])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id DAA08674
	for <xemacs-beta@xemacs.org>; Mon, 14 Apr 1997 03:32:15 -0500 (CDT)
Received: from localhost (kasahara@localhost [127.0.0.1]) by elvenbow.nc.kyushu-u.ac.jp (8.8.5/3.5Wbeta) with ESMTP
	id RAA08893 for <xemacs-beta@xemacs.org>; Mon, 14 Apr 1997 17:31:44 +0900 (JST)
To: xemacs-beta@xemacs.org
Subject: Re: Native sound support for BSD/OS (unsuccessful yet)
In-Reply-To: Your message of "Sun, 13 Apr 1997 17:11:17 +0900"
References: <19970413171117Q.kasahara@nc.kyushu-u.ac.jp>
X-Mailer: Mew version 1.69 on XEmacs 20.1
X-Fingerprint: 31 DC 9F DF C2 B9 8E 00  3A 7C 4F 0C 03 D8 AC 16
X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19970414173141W.kasahara@nc.kyushu-u.ac.jp>
Date: Mon, 14 Apr 1997 17:31:41 +0900
From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
X-Dispatcher: impost version 0.99+ (Mar. 3, 1997)
Lines: 53

On Sun, 13 Apr 1997 17:11:17 +0900,
	Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp> said:

> I tried beta15 (using a fresh tarball), but it dumped core on the same
> line.

I tried to disassemble around that line by GDB.

#0  0x9d218 in linux_play_data_or_file (fd=-1, data=0xefbfd1bc ".snd", length=565, volume=75) at linuxplay.c:981

0x9d214 <linux_play_data_or_file+148>:  pushl  $0x0
0x9d216 <linux_play_data_or_file+150>:  pushl  $0x5
0x9d218 <linux_play_data_or_file+152>:  movl   $0x9d134,0x2b4c04  <-SEGV here
0x9d222 <linux_play_data_or_file+162>:  pushl  $0x9d134
0x9d227 <linux_play_data_or_file+167>:  call   0xaf880 <sys_open>
0x9d22c <linux_play_data_or_file+172>:  movl   %eax,0x2b4c00
0x9d231 <linux_play_data_or_file+177>:  addl   $0xc,%esp
0x9d234 <linux_play_data_or_file+180>:  testl  %eax,%eax
0x9d236 <linux_play_data_or_file+182>:  jge    0x9d2c0 <linux_play_data_or_file+320>

'0x2b4c04' is the address of audio_dev.  So SEGV occured on
'audio_dev="/dev/dsp"'.

Then, I tried to remove the assignment for audio_dev from the line,
recompiled, executed it inside GDB, caused SEGV, and disassembled the
same lines.

#0  0x9d222 in linux_play_data_or_file (fd=-1, data=0xefbfd174 ".snd", length=565, volume=75) at linuxplay.c:981

0x9d214 <linux_play_data_or_file+148>:  pushl  $0x0
0x9d216 <linux_play_data_or_file+150>:  pushl  $0x5
0x9d218 <linux_play_data_or_file+152>:  pushl  $0x9d134
0x9d21d <linux_play_data_or_file+157>:  call   0xaf874 <sys_open>
0x9d222 <linux_play_data_or_file+162>:  movl   %eax,0x2b4c00   <-SEGV here
0x9d227 <linux_play_data_or_file+167>:  addl   $0xc,%esp
0x9d22a <linux_play_data_or_file+170>:  testl  %eax,%eax
0x9d22c <linux_play_data_or_file+172>:  jge    0x9d2b4 <linux_play_data_or_file+308>

'0x2b4c00' is the address of audio_fd.  SEGV while assigning a return
value from sys_open to audio_fd.

Still I can access these variables in GDB.  Why?

I'm blindly searching for clues now because I don't know the detail of
internal of XEmacs, so I may be off the point.

Any suggestions?
-- 
Yoshiaki Kasahara
KITE Network Operation Center, Computer Center, Kyushu University

Email addr:                           |  I'm free!   & ~ __-^-_/~
    kasahara@nc.kyushu-u.ac.jp        |               ~   \___/

