Archive-Date: Fri, 7 Nov 1997 11:45:45 +0100 Message-ID: <199711071045.LAA00186@zafir.e.kth.se> To: Peter.Mroz@parexel.com CC: gnu-emacs-bugs@vms.gnu.ai.mit.edu Subject: Re: Fixed problems In-Reply-To: Your message of "Wed, 05 Nov 1997 17:01:04 EST." <0001F087.1434@parexel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Nov 1997 11:45:41 +0100 From: "Richard 'Gizmo' Levitte" Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, levitte@e.kth.se Hello, Peter, First of all, levitte@e.kth.se is an address I VERY seldom use these days. The correct address to send reports to is gnu-emacs-bugs@vms.gnu.ai.mit.edu. Then to your question: > It appears that the command procedure [.vms]canonicaldir.com was > providing the [.vms]copy.com procedure with erroneous information. I > replaced copy.com with the following code and emacs installed > successfully. Is the original copy.com really necessary? It's unfortunate that you didn't debug it further, but anyway, I want to ask you exactly which revision of Emacs you were playing with, and how you configured, and the values of the logical names that you used. Yes, my copy.com is necessary if you consider how the usual COPY works in a search list. ================================================================================ Archive-Date: Wed, 19 Nov 1997 20:40:04 +0100 Message-ID: <3.0.3.32.19971119113945.008ff550@osshe.edu> Date: Wed, 19 Nov 1997 11:39:45 -0800 To: gnu-emacs-bugs@lp.se From: Dan Sugalski Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, sugalskd@osshe.edu Subject: Emacs 19.28 (19970601) dying with a --sbrk(0) error MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Emacs 19.28 (19970601) dies on me with this error: __sbrk(0) gave me 4D0000, which is in the middle of the code! %SYSTEM-F-DEBUG, command interpreter debugger signal at PC=000B61F8, PS=0000001B Improperly handled condition, image exit forced. Signal arguments: Number = 00000003 Name = 0000046C 000B61F8 0000001B Register dump: R0 = 0000000000000001 R1 = 0000000000014EA8 R2 = 000000000001C990 R3 = 0000000000000001 R4 = 0000000000190FD8 R5 = 0000000000000000 R6 = 0000000000000400 R7 = 0000000000000002 R8 = 0000000000000000 R9 = 000000007ED51730 R10 = 0000000000000280 R11 = 0000000000000000 R12 = 0000000000000003 R13 = 0000000000228014 R14 = 000000000019DD70 R15 = 0000000000001965 R16 = 000000000000046C R17 = 0000000000000001 R18 = 00000000004D2080 R19 = FFFFFFFFFFFFFFFF R20 = 0000000000000000 R21 = 000000000000FFFF R22 = 0000000000000000 R23 = 00000000003B9654 R24 = 0000000000000000 R25 = 0000000000000001 R26 = 00000000000B61F8 R27 = 000000007EF6EAF0 R28 = 100000000000001B R29 = 000000007ED511D0 SP = 000000007ED511D0 PC = 00000000000B61F8 PS = 100000000000001B Compiler: Dec C 5.0-003 System: VMS 6.2-1h3 (8400/5, quad processors, 4G memory) TCP/IP: Multinet 4.0b (Compiled with --with-ucx) Switches to configure: --with-x11, --with-ucx, --prefix=its$common:[yoyo.gnu] DecWindows 1.2-4 The problem triggers after a (fairly small) amount of data's read in. For example, when running as an X app, trying to edit or load cperl-mode.el from the perl distribution kills emacs (408 blocks), as does reading in a 125 block text file. However, when running as a text app (no SET DISPLAY) editing either of these files works. Editing both will kill emacs. Dan ---------------------------------------------"it's like this"-------------- Dan Sugalski (541) 737-3346 even samurai SysAdmin have teddy bears Oregon State system of Higher Education and even the teddy bears sugalskd@osshe.edu get drunk ================================================================================ Archive-Date: Wed, 19 Nov 1997 23:32:41 +0100 Date: Wed, 19 Nov 1997 23:32:36 +0100 Message-ID: <7348-Wed19Nov199723:32:36+0100-levitte@lp.se> From: Richard Levitte - VMS Whacker Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, levitte@lp.se To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, sugalskd@osshe.edu In-Reply-To: <3.0.3.32.19971119113945.008ff550@osshe.edu> (message from Dan Sugalski on Wed, 19 Nov 1997 11:39:45 -0800) Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error MIME-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The problem triggers after a (fairly small) amount of data's read in. I take it it's reproducable? If it is, perhaps you could help me debug it? There are several ways to do this: 1. find the commented `#define DEBUG_VMSGMALLOC' in vmsgmalloc.c and uncomment it. Then recompile. Warning: this will make EMacs spew a lot of data to SYS$ERROR. You might want to redefine that one to point to a file. 2. rebuild with debugging options. A simple `MMS/IGN=W DEBUG' is sufficient. 3. rebuild with the debug hack that will call up the debugger when a serious error occurs. That demands a reconfiguration with the option `--with-debug-hack'. In all cases, to test, you don't need to install. Just do the following: $ @[.VMS]TESTEMACS and you'll get the symbol RUNTEMACS. You can even make it work instead of your normal Emacs by doing the following as well: $ RUNEMACS -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://richard.levitte.org/ for my public key. bastard@bofh.se "price, performance, quality. Choose any two you like" ================================================================================ Archive-Date: Thu, 20 Nov 1997 00:13:05 +0100 Message-ID: <3.0.3.32.19971119151246.008e3a50@osshe.edu> Date: Wed, 19 Nov 1997 15:12:46 -0800 To: Richard Levitte - VMS Whacker , gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU From: Dan Sugalski Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, sugalskd@osshe.edu Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error In-Reply-To: <7348-Wed19Nov199723:32:36+0100-levitte@lp.se> References: <3.0.3.32.19971119113945.008ff550@osshe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:32 PM 11/19/1997 +0100, Richard Levitte - VMS Whacker wrote: > The problem triggers after a (fairly small) amount of data's read in. > >I take it it's reproducable? If it is, perhaps you could help me debug >it? There are several ways to do this: > > 1. find the commented `#define DEBUG_VMSGMALLOC' in vmsgmalloc.c and > uncomment it. Then recompile. Warning: this will make EMacs spew a > lot of data to SYS$ERROR. You might want to redefine that one to > point to a file. Just did this. It does *not* die, which is very, very annoying. Do you still want the output from the log? > 2. rebuild with debugging options. A simple `MMS/IGN=W DEBUG' is > sufficient. > 3. rebuild with the debug hack that will call up the debugger when a > serious error occurs. That demands a reconfiguration with the > option `--with-debug-hack'. I haven't tried either of 2 or 3 yet. I'm going to de-define DEBUG_VMSGMALLOC and rebuild with the debugger next, though, and see how it goes. Dan ---------------------------------------------"it's like this"-------------- Dan Sugalski (541) 737-3346 even samurai SysAdmin have teddy bears Oregon State system of Higher Education and even the teddy bears sugalskd@osshe.edu get drunk ================================================================================ Archive-Date: Thu, 20 Nov 1997 00:20:32 +0100 Date: Thu, 20 Nov 1997 00:20:25 +0100 Message-ID: <4703-Thu20Nov199700:20:25+0100-levitte@lp.se> From: Richard Levitte - VMS Whacker Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, levitte@lp.se To: Dan Sugalski CC: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU In-Reply-To: <3.0.3.32.19971119151246.008e3a50@osshe.edu> (message from Dan Sugalski on Wed, 19 Nov 1997 15:12:46 -0800) Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error MIME-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > 1. find the commented `#define DEBUG_VMSGMALLOC' in vmsgmalloc.c and > uncomment it. Then recompile. Warning: this will make EMacs spew a > lot of data to SYS$ERROR. You might want to redefine that one to > point to a file. Just did this. It does *not* die, which is very, very annoying. Do you still want the output from the log? Only if you found something you think is unusual (I know, the output is not the easiest to understand). > 2. rebuild with debugging options. A simple `MMS/IGN=W DEBUG' is > sufficient. > 3. rebuild with the debug hack that will call up the debugger when a > serious error occurs. That demands a reconfiguration with the > option `--with-debug-hack'. I haven't tried either of 2 or 3 yet. I'm going to de-define DEBUG_VMSGMALLOC and rebuild with the debugger next, though, and see how it goes. Do so, please. -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://richard.levitte.org/ for my public key. bastard@bofh.se "price, performance, quality. Choose any two you like" ================================================================================ Archive-Date: Thu, 20 Nov 1997 00:25:39 +0100 Message-ID: <3.0.3.32.19971119152526.008e8100@osshe.edu> Date: Wed, 19 Nov 1997 15:25:26 -0800 To: Richard Levitte - VMS Whacker From: Dan Sugalski Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, sugalskd@osshe.edu Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error CC: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU In-Reply-To: <4703-Thu20Nov199700:20:25+0100-levitte@lp.se> References: <3.0.3.32.19971119151246.008e3a50@osshe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:20 AM 11/20/1997 +0100, Richard Levitte - VMS Whacker wrote: > > 1. find the commented `#define DEBUG_VMSGMALLOC' in vmsgmalloc.c and > > uncomment it. Then recompile. Warning: this will make EMacs spew a > > lot of data to SYS$ERROR. You might want to redefine that one to > > point to a file. > > Just did this. It does *not* die, which is very, very annoying. Do you > still want the output from the log? > >Only if you found something you think is unusual (I know, the output is >not the easiest to understand). Well, there are a bunch of these: * vms_brk_current = 0x48C000, vms_brk_end = 0x4C0000, sbrk(0) = 0x4C0000, ptr = 0x48C000 end of memory moved from 0x4C0000 to 0x48C000 (should be 48C000). in there. (With different addresses each time) That doesn't look all that good to me, but it might well be fine. > > 2. rebuild with debugging options. A simple `MMS/IGN=W DEBUG' is > > sufficient. > > 3. rebuild with the debug hack that will call up the debugger when a > > serious error occurs. That demands a reconfiguration with the > > option `--with-debug-hack'. > > I haven't tried either of 2 or 3 yet. I'm going to de-define > DEBUG_VMSGMALLOC and rebuild with the debugger next, though, and see how it > goes. > >Do so, please. Well, rebuilding with the debugger results in a perfectly normally working emacs. :( I'm rebuilding with the conditional debugger hack to see if that pops up something more interesting. Dan ---------------------------------------------"it's like this"-------------- Dan Sugalski (541) 737-3346 even samurai SysAdmin have teddy bears Oregon State system of Higher Education and even the teddy bears sugalskd@osshe.edu get drunk ================================================================================ Archive-Date: Thu, 20 Nov 1997 00:32:37 +0100 Message-ID: <3.0.3.32.19971119153226.008e7c90@osshe.edu> Date: Wed, 19 Nov 1997 15:32:26 -0800 To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, Richard Levitte - VMS Whacker From: Dan Sugalski Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, sugalskd@osshe.edu Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error CC: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU In-Reply-To: <3.0.3.32.19971119152526.008e8100@osshe.edu> References: <4703-Thu20Nov199700:20:25+0100-levitte@lp.se> <3.0.3.32.19971119151246.008e3a50@osshe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 03:25 PM 11/19/1997 -0800, Dan Sugalski wrote: >At 12:20 AM 11/20/1997 +0100, Richard Levitte - VMS Whacker wrote: >> > 1. find the commented `#define DEBUG_VMSGMALLOC' in vmsgmalloc.c and >> > uncomment it. Then recompile. Warning: this will make EMacs spew a >> > lot of data to SYS$ERROR. You might want to redefine that one to >> > point to a file. >> >> Just did this. It does *not* die, which is very, very annoying. Do you >> still want the output from the log? >> >>Only if you found something you think is unusual (I know, the output is >>not the easiest to understand). > >Well, there are a bunch of these: > >* vms_brk_current = 0x48C000, vms_brk_end = 0x4C0000, sbrk(0) = 0x4C0000, >ptr = 0x48C000 > end of memory moved from 0x4C0000 to 0x48C000 (should be 48C000). > >in there. (With different addresses each time) That doesn't look all that >good to me, but it might well be fine. > >> > 2. rebuild with debugging options. A simple `MMS/IGN=W DEBUG' is >> > sufficient. >> > 3. rebuild with the debug hack that will call up the debugger when a >> > serious error occurs. That demands a reconfiguration with the >> > option `--with-debug-hack'. >> >> I haven't tried either of 2 or 3 yet. I'm going to de-define >> DEBUG_VMSGMALLOC and rebuild with the debugger next, though, and see >how it >> goes. >> >>Do so, please. > >Well, rebuilding with the debugger results in a perfectly normally working >emacs. :( I'm rebuilding with the conditional debugger hack to see if that >pops up something more interesting. The conditional debugger build *also* works just fine. On the one hand, this is bad, as it doesn't help in tracking down the error. On the other hand, though... At least I've got an emacs executable that works out OK. I'm going to install it and leave things be for a while. (I'm doing a compiler upgrade next week--maybe Dec C 5.6 has fixed whatever strangeness is causing this. Or maybe it'll trigger it even more, who knows) Dan ---------------------------------------------"it's like this"-------------- Dan Sugalski (541) 737-3346 even samurai SysAdmin have teddy bears Oregon State system of Higher Education and even the teddy bears sugalskd@osshe.edu get drunk ================================================================================ Archive-Date: Thu, 20 Nov 1997 01:04:58 +0100 Date: Thu, 20 Nov 1997 01:04:33 +0100 Message-ID: <8654-Thu20Nov199701:04:33+0100-levitte@lp.se> From: Richard Levitte - VMS Whacker Reply-To: gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU, levitte@lp.se To: Dan Sugalski CC: Richard Levitte - VMS Whacker , gnu-emacs-bugs@LISTS.VMS.GNU.AI.MIT.EDU In-Reply-To: <3.0.3.32.19971119152526.008e8100@osshe.edu> (message from Dan Sugalski on Wed, 19 Nov 1997 15:25:26 -0800) Subject: Re: Emacs 19.28 (19970601) dying with a --sbrk(0) error MIME-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit >Only if you found something you think is unusual (I know, the output is >not the easiest to understand). Well, there are a bunch of these: * vms_brk_current = 0x48C000, vms_brk_end = 0x4C0000, sbrk(0) = 0x4C0000, ptr = 0x48C000 end of memory moved from 0x4C0000 to 0x48C000 (should be 48C000). This happens (and is prefectly correct) when emacs is giving back memory pages to the system. The above just tells you that it has updated the pointer that points to the end of the heap. Well, rebuilding with the debugger results in a perfectly normally working emacs. :( I'm rebuilding with the conditional debugger hack to see if that pops up something more interesting. That it works with debugging set is no great surprise to me. It has happened before. -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://richard.levitte.org/ for my public key. bastard@bofh.se "price, performance, quality. Choose any two you like"