3:10 a.m.
OK, it looks like your whole problem is due to low-memory warnings. i see why you're
getting an infinite loop, and i can fix that; but i still don't know why you're
getting low-memory warnings at all. could you set a breakpoint at
check_memory_limits and step through it and see what values you're getting for
data_start, lim_data, cp, and warnlevel?
Harri Pasanen wrote:
Ben Wing wrote:
>
> the dumping problem gets you when you compile on one machine and run on
> another. you shouldn't see it here. can you get a stack backtrace of some
> sort? figure out why it's exiting? once you've built, you should just be
able
> to run xemacs directly without the further stuff going on -- try just `xemacs'.
> if same problem, run under the debugger, with breakpoints at _abort and _exit
> and __exit [i think that's enough], and see why it's exiting. if you can
get a
> stack trace, we can probably figure out what's going wrong.
>
First, auto-autoloads.el is in the tarball. It gets deleted somewhere
along the make run.
Afterwards only auto-autoloads.elc is left. So if I run the make again,
the second run
complains: "Could Not Find
D:\misc\xemacs-21.1.10\lisp\auto-autoloads.el"
As to why xemacs crashes, it does after all look exactly like the
problem I'm having with the development versions.
I built with debug info, launched xemacs by hand, and got the
backtrace. Its again stack overflow because of an apparently
indefinately recursive call stack.
What throws me off is the malloc(unsigned int 0), at call time it should
be 91... I must be missing something.
malloc(unsigned int 4096) line 661 + 6 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
alloc_lcrecord(unsigned int 91, const lrecord_implementation *
0x011a0020 _lrecord_lstream) line 531 + 9 bytes
allocate_managed_lcrecord(int 689121824) line 2569 + 19 bytes
Lstream_new(const lstream_implementation * 0x011a0130
_lstream_resizing_buffer, const char * 0x011a0830) line 239 + 16 bytes
make_resizing_buffer_output_stream() line 1331 + 15 bytes
emacs_doprnt_string_va(const unsigned char * 0x0116581c, int
-1458550780, int -1, char * 0x00033154) line 837 + 5 bytes
warn_when_safe(int -1458418676, int -1458419660, const char *
0x0116581c) line 5026 + 22 bytes
malloc_warning(const char * 0x0124cd90) line 360 + 28 bytes
check_memory_limits() line 97 + 11 bytes
align(unsigned int 4096) line 443
morecore(unsigned int 4096) line 490 + 9 bytes
malloc(unsigned int 4096) line 661 + 12 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
alloc_lcrecord(unsigned int 91, const lrecord_implementation *
0x011a0020 _lrecord_lstream) line 531 + 9 bytes
allocate_managed_lcrecord(int 689121824) line 2569 + 19 bytes
Lstream_new(const lstream_implementation * 0x011a0130
_lstream_resizing_buffer, const char * 0x011a0830) line 239 + 16 bytes
make_resizing_buffer_output_stream() line 1331 + 15 bytes
emacs_doprnt_string_va(const unsigned char * 0x0116581c, int
-1458550780, int -1, char * 0x00033300) line 837 + 5 bytes
warn_when_safe(int -1458418676, int -1458419660, const char *
0x0116581c) line 5026 + 22 bytes
malloc_warning(const char * 0x0124cd90) line 360 + 28 bytes
check_memory_limits() line 97 + 11 bytes
align(unsigned int 4096) line 443
morecore(unsigned int 4096) line 490 + 9 bytes
malloc(unsigned int 4096) line 661 + 12 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
alloc_lcrecord(unsigned int 91, const lrecord_implementation *
0x011a0020 _lrecord_lstream) line 531 + 9 bytes
allocate_managed_lcrecord(int 689121824) line 2569 + 19 bytes
Lstream_new(const lstream_implementation * 0x011a0130
_lstream_resizing_buffer, const char * 0x011a0830) line 239 + 16 bytes
make_resizing_buffer_output_stream() line 1331 + 15 bytes
emacs_doprnt_string_va(const unsigned char * 0x0116581c, int
-1458550780, int -1, char * 0x000334ac) line 837 + 5 bytes
warn_when_safe(int -1458418676, int -1458419660, const char *
0x0116581c) line 5026 + 22 bytes
malloc_warning(const char * 0x0124cd90) line 360 + 28 bytes
check_memory_limits() line 97 + 11 bytes
align(unsigned int 4096) line 443
morecore(unsigned int 4096) line 490 + 9 bytes
malloc(unsigned int 4096) line 661 + 12 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
alloc_lcrecord(unsigned int 91, const lrecord_implementation *
0x011a0020 _lrecord_lstream) line 531 + 9 bytes
allocate_managed_lcrecord(int 689121824) line 2569 + 19 bytes
Lstream_new(const lstream_implementation * 0x011a0130
_lstream_resizing_buffer, const char * 0x011a0830) line 239 + 16 bytes
make_resizing_buffer_output_stream() line 1331 + 15 bytes
emacs_doprnt_string_va(const unsigned char * 0x0116581c, int
-1458550780, int -1, char * 0x00033658) line 837 + 5 bytes
warn_when_safe(int -1458418676, int -1458419660, const char *
0x0116581c) line 5026 + 22 bytes
malloc_warning(const char * 0x0124cd90) line 360 + 28 bytes
check_memory_limits() line 97 + 11 bytes
align(unsigned int 4096) line 443
morecore(unsigned int 4096) line 490 + 9 bytes
malloc(unsigned int 4096) line 661 + 12 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
alloc_lcrecord(unsigned int 91, const lrecord_implementation *
0x011a0020 _lrecord_lstream) line 531 + 9 bytes
allocate_managed_lcrecord(int 689121824) line 2569 + 19 bytes
Lstream_new(const lstream_implementation * 0x011a0130
_lstream_resizing_buffer, const char * 0x011a0830) line 239 + 16 bytes
make_resizing_buffer_output_stream() line 1331 + 15 bytes
emacs_doprnt_string_va(const unsigned char * 0x0116581c, int
-1458550780, int -1, char * 0x00033804) line 837 + 5 bytes
warn_when_safe(int -1458418676, int -1458419660, const char *
0x0116581c) line 5026 + 22 bytes
malloc_warning(const char * 0x0124cd90) line 360 + 28 bytes
check_memory_limits() line 97 + 11 bytes
align(unsigned int 4096) line 443
morecore(unsigned int 4096) line 490 + 9 bytes
malloc(unsigned int 4096) line 661 + 12 bytes
malloc(unsigned int 0) line 605 + 10 bytes
xmalloc(unsigned int 91) line 392 + 9 bytes
allocate_lisp_storage(unsigned int 91) line 495 + 9 bytes
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
10:13 a.m.
New subject: Xemacs for Win NT
Ben Wing wrote:
OK, it looks like your whole problem is due to low-memory warnings. i see why
you're
getting an infinite loop, and i can fix that; but i still don't know why you're
getting low-memory warnings at all. could you set a breakpoint at
check_memory_limits and step through it and see what values you're getting for
data_start, lim_data, cp, and warnlevel?
In check_memory_limits
+ cp 0x09250000 ""
data_size 135245148
+ data_space_start 0x011552a4 "End of Emacs initialized data"
warn_function 0x0101e4fc malloc_warning(const char *)
warnlevel 0
lim_data 116391936
The value of lim_data is bogus, and I spent some time looking why:
Looks like those variables that should have UNINIT_PTR values
unsigned char *data_region_base = UNINIT_PTR;
unsigned char *data_region_end = UNINIT_PTR;
unsigned char *real_data_region_end = UNINIT_PTR;
from ntheap.c have instead values like
+ data_region_base 0x09100000 ""
+ data_region_end 0x0910c000 ""
+ real_data_region_end 0x0910c000 ""
when entering main(). Thus in ntheap.c, sbrk()
if (data_region_base == UNINIT_PTR)
condition is never true, and data_region_size is never initialized.
This looks like a compiler/linker bug to me, but almost too elementary
to be believable. Unfortunately I don't quickly see how to go around
that. I quickly tried initializing those in the beginning of main, but
it crashed elsewhere.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Maybe you have a suggestion? In the meanwhile I'll try to get the
latest Visual C++ service pack, just in case that it has a cure for
this.
Harri
1:31 p.m.
New subject: Xemacs for Win NT
I verified with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
12.00.8804 for 80x86, which is the Visual C++ service pack 4 compiler
(the latest), and I got exactly the same results.
XEmacs must be doing something funky in the initialization code/linking
stage. While possible, I find it hard to believe that VC++ would trip
over on something so obvious as not properly initializing global
variables...?
Any ideas?
Harri
Harri Pasanen wrote:
Ben Wing wrote:
>
> OK, it looks like your whole problem is due to low-memory warnings. i see why
you're
> getting an infinite loop, and i can fix that; but i still don't know why
you're
> getting low-memory warnings at all. could you set a breakpoint at
> check_memory_limits and step through it and see what values you're getting for
> data_start, lim_data, cp, and warnlevel?
>
In check_memory_limits
+ cp 0x09250000 ""
data_size 135245148
+ data_space_start 0x011552a4 "End of Emacs initialized data"
warn_function 0x0101e4fc malloc_warning(const char *)
warnlevel 0
lim_data 116391936
The value of lim_data is bogus, and I spent some time looking why:
Looks like those variables that should have UNINIT_PTR values
unsigned char *data_region_base = UNINIT_PTR;
unsigned char *data_region_end = UNINIT_PTR;
unsigned char *real_data_region_end = UNINIT_PTR;
from ntheap.c have instead values like
+ data_region_base 0x09100000 ""
+ data_region_end 0x0910c000 ""
+ real_data_region_end 0x0910c000 ""
when entering main(). Thus in ntheap.c, sbrk()
if (data_region_base == UNINIT_PTR)
condition is never true, and data_region_size is never initialized.
This looks like a compiler/linker bug to me, but almost too elementary
to be believable. Unfortunately I don't quickly see how to go around
that. I quickly tried initializing those in the beginning of main, but
it crashed elsewhere.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Maybe you have a suggestion? In the meanwhile I'll try to get the
latest Visual C++ service pack, just in case that it has a cure for
this.
Harri
9069
days inactive
9069
days old
2 comments
2 participants
participants (2)
-
Ben Wing -
Harri Pasanen