* bootstrap error
@ 2006-01-25 13:17 Alexander Klimov
2006-01-25 17:46 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Alexander Klimov @ 2006-01-25 13:17 UTC (permalink / raw
Cc: emacs-devel
Hi.
During bootstrap of cvs head on cygwin I got well-known
DIRENTRY_NONEMPTY error and fixed it with
-#ifdef MSDOS
+#if defined(MSDOS) || defined(CYGWIN)
Unfortunately, bootstrap still fails in a different place:
[...]
./temacs --batch --load loadup bootstrap
Loading loadup.el (source)...
[...]
Loading language/utf-8-lang (source)...
Loading language/georgian (source)...
Loading international/ucs-tables (source)...
mv -f emacs.exe bootstrap-emacs.exe
mv: cannot stat `emacs.exe': No such file or directory
make: *** [bootstrap-emacs.exe] Error 1
May be it is related to the `indian.el' bug problem you are working at...
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-25 13:17 bootstrap error Alexander Klimov
@ 2006-01-25 17:46 ` Eli Zaretskii
2006-01-26 10:21 ` Alexander Klimov
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2006-01-25 17:46 UTC (permalink / raw
Cc: emacs-devel
> Date: Wed, 25 Jan 2006 15:17:33 +0200 (IST)
> From: Alexander Klimov <alserkli@inbox.ru>
> cc: emacs-devel@gnu.org
>
> ./temacs --batch --load loadup bootstrap
> Loading loadup.el (source)...
> [...]
> Loading language/utf-8-lang (source)...
> Loading language/georgian (source)...
> Loading international/ucs-tables (source)...
> mv -f emacs.exe bootstrap-emacs.exe
> mv: cannot stat `emacs.exe': No such file or directory
> make: *** [bootstrap-emacs.exe] Error 1
??? Is this the exact and full fragment of what you see? Did the
build indeed try to "mv -f emacs.exe" right after loading
ucs-tables/el? You will see in loadup.el that quite a few more Lisp
files had to be loaded, and then Emacs should have dumped itself.
>From the fragment you've posted, it looks like Emacs died in the
middle of loadup--is that true?
> May be it is related to the `indian.el' bug problem you are working at...
If it is, then try resyncing with the CVS, because that problem is
already solved there.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-25 17:46 ` Eli Zaretskii
@ 2006-01-26 10:21 ` Alexander Klimov
2006-01-27 13:25 ` Eli Zaretskii
2006-01-27 20:37 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Alexander Klimov @ 2006-01-26 10:21 UTC (permalink / raw
Cc: emacs-devel
On Wed, 25 Jan 2006, Eli Zaretskii wrote:
> > ./temacs --batch --load loadup bootstrap
> > Loading loadup.el (source)...
> > [...]
> > Loading language/utf-8-lang (source)...
> > Loading language/georgian (source)...
> > Loading international/ucs-tables (source)...
> > mv -f emacs.exe bootstrap-emacs.exe
> > mv: cannot stat `emacs.exe': No such file or directory
> > make: *** [bootstrap-emacs.exe] Error 1
>
> ??? Is this the exact and full fragment of what you see? Did the
> build indeed try to "mv -f emacs.exe" right after loading
> ucs-tables/el?
Yes, that is way I guessed that it is the same problem as with
indian.el.
> it looks like Emacs died in the middle of loadup--is that true?
Yes and the newest file in the src directory is temacs.exe (that is
there is no core dump).
> > May be it is related to the `indian.el' bug problem you are working at...
> If it is, then try resyncing with the CVS, because that problem is
> already solved there.
I always update it and ChangeLog has your 2006-01-20 record.
I made the following experiments: in loadup.el I commented out
;;(load "international/ucs-tables")
and temacs starts to silently die at font-lock
;;(update-coding-systems-internal)
same result (font-lock)
;;(load "font-lock")
and it goes to
Loading mouse (source)...
mv -f emacs.exe bootstrap-emacs.exe
removing mouse
;;(load "mouse")
and
Loading language/georgian (source)...
Loading indent (source)...
Loading window (source)...
Loading frame (source)...
Loading term/tty-colors (source)...
Loading font-core (source)...
Loading facemenu (source)...
Loading emacs-lisp/syntax (source)...
Loading jit-lock (source)...
Loading scroll-bar (source)...
mv -f emacs.exe bootstrap-emacs.exe
mv: cannot stat `emacs.exe': No such file or directory
make: *** [bootstrap-emacs.exe] Error 1
I tried to use gdb:
$ gdb ./temacs.exe
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
[...]
DISPLAY = 127.0.0.1:0.0
TERM = xterm
.gdbinit:784: Error in sourced command file:
Cannot access memory at address 0x20000004
(gdb) run --batch --load loadup bootstrap
[...]
Loading language/georgian (source)...
Loading international/ucs-tables (source)...
Program received signal SIGSEGV, Segmentation fault.
0x610f285f in done () from /usr/bin/cygwin1.dll
(gdb) where
#0 0x610f285f in done () from /usr/bin/cygwin1.dll
#1 0x20ac0000 in bss_sbrk_buffer ()
#2 0x610db690 in _vfprintf_r () from /usr/bin/cygwin1.dll
#3 0x610deb48 in vfprintf () from /usr/bin/cygwin1.dll
#4 0x610e81a5 in printf () from /usr/bin/cygwin1.dll
#5 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll
#6 0x007e9f20 in ?? ()
#7 0x00040000 in ?? ()
#8 0x20aa0000 in bss_sbrk_buffer ()
#9 0x00040000 in ?? ()
#10 0x000343c8 in ?? ()
#11 0x2014bab1 in obtain (address=0x202999cc, size=548143104) at
ralloc.c:315
#12 0x2014bab1 in obtain (address=0x202999cc, size=548012032) at
ralloc.c:315
#13 0x2014c7ac in r_alloc_sbrk (size=135168) at ralloc.c:840
#14 0x2014a63b in align (size=3084) at gmalloc.c:461
#15 0x2014b167 in _malloc_internal (size=4096) at gmalloc.c:588
#16 0x2014b1e1 in _malloc_internal (size=1024) at gmalloc.c:763
#17 0x6105340c in malloc () from /usr/bin/cygwin1.dll
#18 0x00000400 in ?? ()
#19 0x00000000 in ?? () from
Lisp Backtrace:
"make-char-table"
"let"
"make-translation-table"
"set"
"let*"
"while"
"let"
"catch"
"cl-block-wrapper"
"block"
"dolist"
"let"
"eval-buffer"
"let"
"unwind-protect"
"let*"
"if"
"load-with-code-conversion"
"load"
"load"
548 Megs seems too large so I take a look on #11:
#11 0x2014bab1 in obtain (address=0x202999cc, size=548143104) at ralloc.c:315
315 if ((*real_morecore) (get) != last_heap->end)
(gdb) p get
$2 = 548143104
(gdb) p last_heap->end
$3 = 0x20ac0000
(gdb) p real_morecore
$5 = (POINTER (*)()) 0x2014b840 <__default_morecore>
(gdb) up
#12 0x2014bab1 in obtain (address=0x202999cc, size=548012032) at
ralloc.c:315
315 if ((*real_morecore) (get) != last_heap->end)
[...]
(gdb) up
#13 0x2014c7ac in r_alloc_sbrk (size=135168) at ralloc.c:840
840 if (! obtain (address, get))
(gdb) p get
$8 = 327680
(gdb) p address
$9 = 0x20aa0000
Something is wrong with this: #13 calls obtain(0x20aa0000,327680) but
#12 is in obtain(0x202999cc,548012032)
I inserted to r_alloc_sbrk
get += extra_bytes + page_size;
+ static unsigned cnt = 0;
+ fprintf(stderr, "* not found (%d), obtain more space: %d\n", ++cnt, get);
if (! obtain (address, get))
return 0;
+ fprintf(stderr, "* OK\n");
and get the following:
Loading language/thai (source)...
Loading language/tibetan (source)...
* not found (16), obtain more space: 327680
* OK
Loading language/vietnamese (source)...
Loading language/misc-lang (source)...
Loading language/utf-8-lang (source)...
Loading language/georgian (source)...
Loading international/ucs-tables (source)...
* not found (17), obtain more space: 327680
* not found (18), obtain more space: 327680
* not found (19), obtain more space: 327680
[...]
* not found (277), obtain more space: 327680
* not found (278), obtain more space: 327680
mv -f emacs.exe bootstrap-emacs.exe
Note that there is no real shortage of memory -- the first time there
is no `* OK' temacs uses only 13 Mb (accorting to task manager), and
there are another ~300 Mb free. Another observation is that even if
obtain does not return anything the memory usage in task manager
increases after each call (up to 16 Mb after `not found' number 278,
that is 10 Kb on average).
I also inserted a debug print into obtain():
+ fprintf(stderr, "* obtain(%d, %d)\n", address, size);
and it is consistent with what was asked:
[...]
Loading language/tibetan (source)...
* not found (16), obtain more space: 327680
* obtain(547815424, 327680)
* OK
* obtain(548012032, 31552)
* obtain(548017880, 24)
Loading language/vietnamese (source)...
* obtain(548018120, 24)
Loading language/misc-lang (source)...
* obtain(548018120, 24)
Loading language/utf-8-lang (source)...
* obtain(548018120, 24)
Loading language/georgian (source)...
* obtain(548018120, 24)
Loading international/ucs-tables (source)...
* not found (17), obtain more space: 327680
* obtain(548012032, 327680)
* not found (18), obtain more space: 327680
* obtain(548012032, 327680)
[...]
so the backtrace was screwed up.
I made yet another experiment -- add printout to each return in
obtain() to check what is the reason of no `* OK' and it looks like
obtain just not return at all. This is what I added:
obtain (address, size)
[...]
+ fprintf(stderr, "* obtain(%d, %d), heap = %d\n", address, size, heap);
if (! heap)
abort ();
[...]
if ((*real_morecore) ((char *) bloc_start - (char *) new) != new){
+ fprintf(stderr, "* cannot make a new heap: %d - %d\n", bloc_start, new);
return 0;
}
[...]
if ((*real_morecore) (get) != last_heap->end){
+ fprintf(stderr, "* cannot get some extra %d\n", get);
return 0;
+ }
[...]
+ fprintf(stderr, "* obtain() returns %d\n", address);
return address;
and this is what I get:
Loading language/tibetan (source)...
* not found (16), obtain more space: 327680
* obtain(547815424, 327680), heap = 539798416
* obtain() returns 547815424
* OK
* obtain(548012032, 31552), heap = 539798416
* obtain() returns 548012032
* obtain(548017880, 24), heap = 539798416
* obtain() returns 548017880
Loading language/vietnamese (source)...
* obtain(548018120, 24), heap = 539798416
* obtain() returns 548018120
Loading language/misc-lang (source)...
* obtain(548018120, 24), heap = 539798416
* obtain() returns 548018120
Loading language/utf-8-lang (source)...
* obtain(548018120, 24), heap = 539798416
* obtain() returns 548018120
Loading language/georgian (source)...
* obtain(548018120, 24), heap = 539798416
* obtain() returns 548018120
Loading international/ucs-tables (source)...
* not found (17), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798416
* not found (18), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798416
[...]
* not found (277), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798416
* not found (278), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798416
mv -f emacs.exe bootstrap-emacs.exe
mv: cannot stat `emacs.exe': No such file or directory
make: *** [bootstrap-emacs.exe] Error 1
Any ideas? BTW, this host has cygwin1.dll 1.5.19-4 (build date
2006-01-20 13:28), gcc 3.4.4, and Win2K.
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-26 10:21 ` Alexander Klimov
@ 2006-01-27 13:25 ` Eli Zaretskii
2006-01-28 9:50 ` Alexander Klimov
2006-01-27 20:37 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2006-01-27 13:25 UTC (permalink / raw
Cc: emacs-devel
> Date: Thu, 26 Jan 2006 12:21:01 +0200 (IST)
> From: Alexander Klimov <alserkli@inbox.ru>
> cc: emacs-devel@gnu.org
>
> > > Loading international/ucs-tables (source)...
> > > mv -f emacs.exe bootstrap-emacs.exe
> > > mv: cannot stat `emacs.exe': No such file or directory
> > > make: *** [bootstrap-emacs.exe] Error 1
> >
> > ??? Is this the exact and full fragment of what you see? Did the
> > build indeed try to "mv -f emacs.exe" right after loading
> > ucs-tables/el?
>
> Yes, that is way I guessed that it is the same problem as with
> indian.el.
But indian.el was loaded already, long ago, at the point where
ucs-tables are loaded. So I doubt that this has anything to do with
that problem, and it was fixed already anyway.
> I tried to use gdb:
>
> $ gdb ./temacs.exe
> GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
It's better to install a newer version of GDB: the backtrace code got
improved in the year that passed since that version was built.
> Loading international/ucs-tables (source)...
> * not found (17), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> * not found (18), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> [...]
> * not found (277), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> * not found (278), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> mv -f emacs.exe bootstrap-emacs.exe
> mv: cannot stat `emacs.exe': No such file or directory
> make: *** [bootstrap-emacs.exe] Error 1
>
> Any ideas?
Not yet, but I might have some ideas later. Emacs bootstraps (with
MinGW) just fine on my XP box. But if I run temacs inside GDB, I see
that loading ucs-tables.el causes `obtain' to be called 3 times with
these arguments:
Breakpoint 3, obtain (address=0x192c458, size=24) at ralloc.c:255
255 for (heap = last_heap; heap; heap = heap->prev)
(gdb)
Continuing.
Loading international/ucs-tables (source)...
Breakpoint 3, obtain (address=0x192c458, size=102512) at ralloc.c:255
255 for (heap = last_heap; heap; heap = heap->prev)
(gdb)
Continuing.
Breakpoint 3, obtain (address=0x193f458, size=102512) at ralloc.c:255
255 for (heap = last_heap; heap; heap = heap->prev)
Then I see an error message:
Attempt to autoload define-minor-mode while preparing to dump
And then it aborts. So I kinda can reproduce your problem, although
it doesn't prevent bootstrapping on my system.
I will try to find out why this error message is being printed, but
note that I don't see any such message during the actual bootstrap,
only when I run temacs _after_ bootstrapping.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-26 10:21 ` Alexander Klimov
2006-01-27 13:25 ` Eli Zaretskii
@ 2006-01-27 20:37 ` Eli Zaretskii
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2006-01-27 20:37 UTC (permalink / raw
Cc: emacs-devel
> Date: Thu, 26 Jan 2006 12:21:01 +0200 (IST)
> From: Alexander Klimov <alserkli@inbox.ru>
> cc: emacs-devel@gnu.org
>
> Loading international/ucs-tables (source)...
> * not found (17), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> * not found (18), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> [...]
> * not found (277), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> * not found (278), obtain more space: 327680
> * obtain(548012032, 327680), heap = 539798416
> mv -f emacs.exe bootstrap-emacs.exe
> mv: cannot stat `emacs.exe': No such file or directory
> make: *** [bootstrap-emacs.exe] Error 1
>
> Any ideas? BTW, this host has cygwin1.dll 1.5.19-4 (build date
> 2006-01-20 13:28), gcc 3.4.4, and Win2K.
After some more tinkering, I think I know why the error message about
autoloading define-minor-mode doesn't show during bootstrapping. The
function eval.c:do_autoload, which issues that message, does this:
/* This is to make sure that loadup.el gives a clear picture
of what files are preloaded and when. */
if (! NILP (Vpurify_flag))
error ("Attempt to autoload %s while preparing to dump",
SDATA (SYMBOL_NAME (funname)));
So this message and the resulting abort should only happen when
purify-flag is non-nil. However, loadup.el does this:
(if (or (equal (nth 3 command-line-args) "bootstrap")
(equal (nth 4 command-line-args) "bootstrap")
;; in case CANNOT_DUMP
(equal (nth 0 command-line-args) "../src/bootstrap-emacs"))
(let ((dir (car load-path)))
;; We'll probably overflow the pure space.
(setq purify-flag nil)
(setq load-path (list dir
(expand-file-name "emacs-lisp" dir)
(expand-file-name "language" dir)
(expand-file-name "international" dir)
(expand-file-name "textmodes" dir)))))
So during bootstrap, purify-flag is nil, and the error never happens.
So now the question is, why doesn't this work for Cygwin? Doesn't
Cygwin support dumping or something? is purify-flag indeed nil during
bootstrap of the Cygwin port? or maybe some of your investigations
were not in the bootstrap context, so purify-flag was non-nil?
And another puzzle: if autoloading define-minor-mode aborts the Cygwin
bootstrap, why doesn't that happen earlier, in help.el, for example,
which also uses define-minor-mode?
Finally, just to make sure we are not chasing a wild goose, could you
please see if the message about autoloading define-minor-mode is
indeed the reason for the abort?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-27 13:25 ` Eli Zaretskii
@ 2006-01-28 9:50 ` Alexander Klimov
2006-01-28 14:01 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Alexander Klimov @ 2006-01-28 9:50 UTC (permalink / raw
Cc: emacs-devel
On Fri, 27 Jan 2006, Eli Zaretskii wrote:
> > Yes, that is way I guessed that it is the same problem as with
> > indian.el.
>
> But indian.el was loaded already, long ago, at the point where
> ucs-tables are loaded. So I doubt that this has anything to do with
> that problem, and it was fixed already anyway.
What I wanted to say is that it looks like (what I understand was) the
indian.el problem -- some resource is slowly exhausted and so the
error manifests itself in some random place afterwards. First I get
bootstrap failure at ucs-tables, when I remove ucs-tables I get the
same failure at some next module, when I remove that new module --
another one failed. My point was that it looks like ucs-tables or
other failed modules have nothing to do with the reason of the error.
> Emacs bootstraps (with MinGW) just fine on my XP box. But if I run
> temacs inside GDB, I see that loading ucs-tables.el causes `obtain'
> to be called 3 times [...] Then I see an error message:
>
> Attempt to autoload define-minor-mode while preparing to dump
>
> And then it aborts. So I kinda can reproduce your problem, although
> it doesn't prevent bootstrapping on my system.
Probably it is some interaction with gdb? In my case obtain was called
during bootstrap hundreds of time and in your case it failed after
three.
> I will try to find out why this error message is being printed, but
> note that I don't see any such message during the actual bootstrap,
> only when I run temacs _after_ bootstrapping.
I have not seen *any* error messages during bootstrap -- it just
silently failed.
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-28 9:50 ` Alexander Klimov
@ 2006-01-28 14:01 ` Eli Zaretskii
2006-01-29 8:08 ` Alexander Klimov
2006-01-29 17:51 ` Alexander Klimov
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2006-01-28 14:01 UTC (permalink / raw
Cc: emacs-devel
> Date: Sat, 28 Jan 2006 11:50:12 +0200 (IST)
> From: Alexander Klimov <ask@eitan.edu>
> cc: emacs-devel@gnu.org
>
> What I wanted to say is that it looks like (what I understand was) the
> indian.el problem -- some resource is slowly exhausted and so the
> error manifests itself in some random place afterwards. First I get
> bootstrap failure at ucs-tables, when I remove ucs-tables I get the
> same failure at some next module, when I remove that new module --
> another one failed. My point was that it looks like ucs-tables or
> other failed modules have nothing to do with the reason of the error.
That is probably so. But I cannot reproduce anything like that on
Windows without Cygwin, so you will have to debug this on your machine
and tell here your findings. That is the only practical way to debug
this.
> > Attempt to autoload define-minor-mode while preparing to dump
> >
> > And then it aborts. So I kinda can reproduce your problem, although
> > it doesn't prevent bootstrapping on my system.
>
> Probably it is some interaction with gdb?
I'm not sure. As I explained in a follow-up message, the error
message happened because I didn't run temacs with the "bootstrap"
argument on the command line.
> In my case obtain was called during bootstrap hundreds of time and
> in your case it failed after three.
There should be no reason for it to call obtain so many times, and
moreover, it calls it with the same arguments again and again.
Perhaps try downgrading to the previous version of Cygwin--there might
be some bug in the latest version.
> I have not seen *any* error messages during bootstrap -- it just
> silently failed.
The silent failure is another puzzle: did it abort? did it exit with a
failure indication? Perhaps putting a breakpoint on the lowest-level
exit routine you can will shed some light on this.
Anyway, thanks for working on this.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-28 14:01 ` Eli Zaretskii
@ 2006-01-29 8:08 ` Alexander Klimov
2006-01-29 19:37 ` Eli Zaretskii
2006-01-29 17:51 ` Alexander Klimov
1 sibling, 1 reply; 16+ messages in thread
From: Alexander Klimov @ 2006-01-29 8:08 UTC (permalink / raw
Cc: emacs-devel
On Sat, 28 Jan 2006, Eli Zaretskii wrote:
> Perhaps try downgrading to the previous version of Cygwin--there might
> be some bug in the latest version.
I have no doubt about it -- I currently use emacs which was built from
cvs on 2006-01-16 (before I upgraded cygwin) and the problems with
build starts to appear only *after* the last cygwin update.
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-28 14:01 ` Eli Zaretskii
2006-01-29 8:08 ` Alexander Klimov
@ 2006-01-29 17:51 ` Alexander Klimov
1 sibling, 0 replies; 16+ messages in thread
From: Alexander Klimov @ 2006-01-29 17:51 UTC (permalink / raw
Cc: emacs-devel
On Sat, 28 Jan 2006, Eli Zaretskii wrote:
> That is probably so. But I cannot reproduce anything like that on
> Windows without Cygwin, so you will have to debug this on your machine
> and tell here your findings. That is the only practical way to debug
> this.
I added yet another instrumentation:
/* Allocate memory from the heap. */
__ptr_t
_malloc_internal (size)
__malloc_size_t size;
{
+ static unsigned cnt = 0;
+ fprintf(stderr, " mi[%d %d", ++cnt, size);
[...]
PROTECT_MALLOC_STATE (1);
+ fprintf(stderr, " %d]", result);
return result;
The log is huge, but let see some interesting examples:
mi[1 16 mi[2 4096 539860992 ] 539860992 ] // so _malloc_internal can call itself
mi[3 128 mi[4 4096 539860992 ] 539860992 ]
[...]
Loading language/czech (source)...
mi[11497 16336
* not found (13), obtain more space: 327680
* obtain(547618816, 327680), heap = 539798432
* obtain() returns 547618816
* OK
547618816] // _malloc_internal can call obtain but obtain does not call back
mi[11498 12 539960624]
[...]
mi[12090 528 547870720]
mi[12091 528 547869696]
mi[12092 528 mi[12093 4096 //_malloc_internal was called recursively
* not found (14), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798432
mi[12094 1024 mi[12095 4096 // and obtain calls _malloc_internal again!
* not found (15), obtain more space: 327680
* obtain(548012032, 327680), heap = 539798432
mi[12096 1024 mi[12097 4096
* not found (16), obtain more space: 327680
[...]
So, from some point on obtain starts to call _malloc_internal back,
futhermore, gdb shows that malloc() from /usr/bin/cygwin1.dll calls
malloc from gmalloc.c.
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-29 8:08 ` Alexander Klimov
@ 2006-01-29 19:37 ` Eli Zaretskii
2006-01-30 9:11 ` Alexander Klimov
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2006-01-29 19:37 UTC (permalink / raw
Cc: emacs-devel
> Date: Sun, 29 Jan 2006 10:08:42 +0200 (IST)
> From: Alexander Klimov <alserkli@inbox.ru>
> cc: emacs-devel@gnu.org
>
> On Sat, 28 Jan 2006, Eli Zaretskii wrote:
> > Perhaps try downgrading to the previous version of Cygwin--there might
> > be some bug in the latest version.
>
> I have no doubt about it -- I currently use emacs which was built from
> cvs on 2006-01-16 (before I upgraded cygwin) and the problems with
> build starts to appear only *after* the last cygwin update.
Then it's probably a good idea to post the information you found on
the Cygwin mailing list. Perhaps they will be able to suggest
solutions or otherwise shed some light on this problem.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-29 19:37 ` Eli Zaretskii
@ 2006-01-30 9:11 ` Alexander Klimov
2006-01-30 11:38 ` Corinna Vinschen
0 siblings, 1 reply; 16+ messages in thread
From: Alexander Klimov @ 2006-01-30 9:11 UTC (permalink / raw
Cc: emacs-devel
On Sun, 29 Jan 2006, Eli Zaretskii wrote:
> > From: Alexander Klimov <alserkli@inbox.ru>
> >
> > On Sat, 28 Jan 2006, Eli Zaretskii wrote:
> > > Perhaps try downgrading to the previous version of Cygwin--there might
> > > be some bug in the latest version.
I made the following experiment: I installed cygwin 1.5.18-1 and now
./temacs.exe --batch --load loadup bootstrap
creates emacs.exe
BTW, I have not rebuild temacs because most of build tools are
not compatible with the old cygwin dll, e.g., rm produces an error
The procedure entry point getline could not be located in the [DLL]
cygwin1.dll
I reverted back to 19-4 and now temacs again fails with apparent
recursion (malloc() from cygwin1.dll calls malloc from temacs).
> > I have no doubt about it -- I currently use emacs which was built from
> > cvs on 2006-01-16 (before I upgraded cygwin) and the problems with
> > build starts to appear only *after* the last cygwin update.
>
> Then it's probably a good idea to post the information you found on
> the Cygwin mailing list. Perhaps they will be able to suggest
> solutions or otherwise shed some light on this problem.
The problem is that I have no idea what to tell them: temacs fails
with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a
reasonable bug report.
Let me put the question differently: what was changed between 18-1 and
19-4 in the DLL (note that .h files are irrelevant since I used temacs
built with 19-4).
Cygwin gurus, the start of the thread is here
<http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html>
--
Regards,
ASK
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2006-01-30 9:11 ` Alexander Klimov
@ 2006-01-30 11:38 ` Corinna Vinschen
0 siblings, 0 replies; 16+ messages in thread
From: Corinna Vinschen @ 2006-01-30 11:38 UTC (permalink / raw
Cc: emacs-devel, Eli Zaretskii
On Jan 30 11:11, Alexander Klimov wrote:
> On Sun, 29 Jan 2006, Eli Zaretskii wrote:
> > Then it's probably a good idea to post the information you found on
> > the Cygwin mailing list. Perhaps they will be able to suggest
> > solutions or otherwise shed some light on this problem.
>
> The problem is that I have no idea what to tell them: temacs fails
> with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a
> reasonable bug report.
>
> Let me put the question differently: what was changed between 18-1 and
> 19-4 in the DLL (note that .h files are irrelevant since I used temacs
> built with 19-4).
>
> Cygwin gurus, the start of the thread is here
> <http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html>
Sorry, I can't make a lot out of this error report. Please try to nail
down the problem somewhat further, for instance, by providing a minimal
testcase which allows to reproduce the problem with a minimum of
involved code.
Since this revolves around malloc, it might be worth to note that two
changes to malloc have been made in Cygwin between 1.5.18 and 1.5.19.
First, we switched from Doug Lea's malloc implementation version 2.8.0
to 2.8.3, second, due to a reworked mmap implementation, which uses
simple VirtualAlloc for private anonymous maps, we lowered the
DEFAULT_MMAP_THRESHOLD from 16 Megs to the usual default of 256K.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Bootstrap error
2007-08-24 10:08 ` David Kastrup
@ 2007-08-24 10:41 ` B. Anyos
0 siblings, 0 replies; 16+ messages in thread
From: B. Anyos @ 2007-08-24 10:41 UTC (permalink / raw
To: emacs-devel
Hi,
I have a bootstrap error as follows:
[...]
Compiling /e/Tools/emacs/lisp/emacs-lisp/byte-opt.el
In toplevel form:
emacs-lisp/byte-opt.el:288:51:Error: Wrong type argument: listp, restp
Compiling /e/Tools/emacs/lisp/emacs-lisp/bytecomp.el
In toplevel form:
emacs-lisp/bytecomp.el:213:38:Error: Wrong type argument: listp, handler
Compiling /e/Tools/emacs/lisp/subr.el
In toplevel form:
subr.el:229:29:Error: Wrong type argument: listp, n
Compiling /e/Tools/emacs/lisp/progmodes/cc-mode.el
In toplevel form:
progmodes/cc-mode.el:170:13:Error: Wrong type argument: listp, source-eval
Compiling /e/Tools/emacs/lisp/progmodes/cc-vars.el
In toplevel form:
progmodes/cc-vars.el:83:19:Error: Wrong type argument: listp, l
make[1]: *** [compile-SH] Error 1
make[1]: Leaving directory `/e/Tools/emacs/lisp'
make: *** [bootstrap-gmake] Error 2
I've freshly taken sources from CVS. Would anyone solve this?
Regards,
Bela
^ permalink raw reply [flat|nested] 16+ messages in thread
* bootstrap error
@ 2016-10-02 19:48 Colin Baxter
2016-10-02 20:22 ` Philipp Stephani
0 siblings, 1 reply; 16+ messages in thread
From: Colin Baxter @ 2016-10-02 19:48 UTC (permalink / raw
To: emacs-devel
I get a bootstrap Error 255; value as variable is void:
blink-cursor-idle-timer. It might be commit e0ac099 since when I revert
that commit the error goes away and the build is successful.
Colin Baxter
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2016-10-02 19:48 bootstrap error Colin Baxter
@ 2016-10-02 20:22 ` Philipp Stephani
2016-10-03 5:25 ` Colin Baxter
0 siblings, 1 reply; 16+ messages in thread
From: Philipp Stephani @ 2016-10-02 20:22 UTC (permalink / raw
To: Colin Baxter, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
Colin Baxter <m43cap@yandex.com> schrieb am So., 2. Okt. 2016 um 21:49 Uhr:
>
> I get a bootstrap Error 255; value as variable is void:
> blink-cursor-idle-timer. It might be commit e0ac099 since when I revert
> that commit the error goes away and the build is successful.
>
Whoops, sorry, should be fixed now.
[-- Attachment #2: Type: text/html, Size: 668 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: bootstrap error
2016-10-02 20:22 ` Philipp Stephani
@ 2016-10-03 5:25 ` Colin Baxter
0 siblings, 0 replies; 16+ messages in thread
From: Colin Baxter @ 2016-10-03 5:25 UTC (permalink / raw
To: Philipp Stephani; +Cc: emacs-devel
Hello Philipp,
On Sun, Oct 02 2016, Philipp Stephani wrote:
> Colin Baxter <m43cap@yandex.com> schrieb am So., 2. Okt. 2016 um 21:49 Uhr:
>
> I get a bootstrap Error 255; value as variable is void:
> blink-cursor-idle-timer. It might be commit e0ac099 since when I revert
> that commit the error goes away and the build is successful.
>
> Whoops, sorry, should be fixed now.
Yes, it's fixed now - thank you.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-10-03 5:25 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-02 19:48 bootstrap error Colin Baxter
2016-10-02 20:22 ` Philipp Stephani
2016-10-03 5:25 ` Colin Baxter
-- strict thread matches above, loose matches on Subject: below --
2007-08-19 3:17 merging etc Miles Bader
[not found] ` <200708211523.l7LFNnVl000876@oogie-boogie.ics.uci.edu>
[not found] ` <buo3aycknp8.fsf@dhapc248.dev.necel.com>
[not found] ` <200708220820.l7M8KbIt026014@oogie-boogie.ics.uci.edu>
[not found] ` <fc339e4a0708220237v3b90ec6fwde90eba1ca936e91@mail.gmail.com>
2007-08-22 11:55 ` Miles Bader
2007-08-22 15:33 ` Stefan Monnier
2007-08-23 0:19 ` Juri Linkov
2007-08-23 20:58 ` Richard Stallman
2007-08-24 8:01 ` joakim
2007-08-24 8:46 ` Leo
2007-08-24 10:08 ` David Kastrup
2007-08-24 10:41 ` Bootstrap error B. Anyos
2006-01-25 13:17 bootstrap error Alexander Klimov
2006-01-25 17:46 ` Eli Zaretskii
2006-01-26 10:21 ` Alexander Klimov
2006-01-27 13:25 ` Eli Zaretskii
2006-01-28 9:50 ` Alexander Klimov
2006-01-28 14:01 ` Eli Zaretskii
2006-01-29 8:08 ` Alexander Klimov
2006-01-29 19:37 ` Eli Zaretskii
2006-01-30 9:11 ` Alexander Klimov
2006-01-30 11:38 ` Corinna Vinschen
2006-01-29 17:51 ` Alexander Klimov
2006-01-27 20:37 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.