Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7)
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
Olivier Galibert <galibert(a)pobox.com> writes:
On Thu, Nov 16, 2000 at 01:24:04PM +0000, Gunnar Evermann wrote:
> Yes, that's what I realised after writing the question and meant by
> "Hm, I guess it is". We should automatically check whether we always
> do this. Maybe in debug_gcpro().
Tricky. There are a number of gcpros done on already instanciated
lisp objects, and nothing looks more like a valid lisp_object than
random garbage. You can't even test for alignment since the lower
bits encode the type information for integers and chars.
Yes, you are right.
Maybe Jan's old idea of using C++ and explicit constructor and
destructor methods for LispObject would work.
We could just inintialise LispObjects to NULL in the constructor. Then
we can check in GCPRO (giving some false positives as they only need
to hold real LispObjects when the GC actually happens). Alternatively
we could have a special function that is always called when a GC could
happen (like always_gc) and then checks the gcprolist for NULLs.
Gunnar
Yoshiki Hayashi
Tuesday, 21 November
Tue, 21 Nov
8:28 a.m.
New subject: GCPRO uninitialized variables
Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes:
We could just inintialise LispObjects to NULL in the constructor.
Then
we can check in GCPRO (giving some false positives as they only need
to hold real LispObjects when the GC actually happens). Alternatively
we could have a special function that is always called when a GC could
happen (like always_gc) and then checks the gcprolist for NULLs.
I used GCC to find them. I replaced GCPRO like following
patch and tried to compile XEmacs. With that patch applied,
you can't build working XEmacs but GCC gives you much more
warning about uninitialized variables, clobbered variable by
setjmp and so on. If I didn't remove actuall GCPRO code,
GCC didn't warn about uninitialized variables. Perhaps it
is because GCPRO add alias to Lisp_Object but I don't know
about the detail. I love GCC for doing this kind of check.
I did it on only Linux. Windows folks should do the same.
Installation file is attached. Source code not compiled are
not checked.
--- /src/xemacs/src/lisp.h Wed Nov 15 19:50:00 2000
+++ /home/penny/lisp.h.gc-uninit-check Sun Nov 19 15:41:46 2000
＠＠ -1953,6 +1953,25 ＠＠
#else /* ! DEBUG_GCPRO */
+#define GCPRO1(var1) Fcar (var1);
+#define GCPRO2(var1, var2) Fcar (var1); Fcar (var2);
+#define GCPRO3(var1, var2, var3) Fcar (var1); Fcar (var2); Fcar (var3);
+#define GCPRO4(var1, var2, var3, var4) Fcar (var1); Fcar (var2); Fcar (var3); Fcar
(var4);
+#define GCPRO5(var1, var2, var3, var4, var5) Fcar (var1); Fcar (var2); Fcar (var3); Fcar
(var4); Fcar (var5);
+#define UNGCPRO ((void) (gcprolist = gcpro1.next))
+#define NUNGCPRO ((void) 1)
+#define NNUNGCPRO ((void) (gcprolist = nngcpro1.next))
+#define NGCPRO1(var1) GCPRO1(var1)
+#define NGCPRO2(var1, var2) GCPRO2(var1, var2)
+#define NGCPRO3(var1, var2, var3) GCPRO3(var1, var2, var3)
+#define NGCPRO4(var1, var2, var3, var4) GCPRO4(var1, var2, var3, var4)
+#define NGCPRO5(var1, var2, var3, var4, var5) GCPRO5(var1, var2, var3, var4, var5)
+#define NNGCPRO1(var1) GCPRO1(var1)
+#define NNGCPRO2(var1, var2) GCPRO2(var1, var2)
+#define NNGCPRO3(var1, var2, var3) GCPRO3(var1, var2, var3)
+#define NNGCPRO4(var1, var2, var3, var4) GCPRO4(var1, var2, var3, var4)
+#define NNGCPRO5(var1, var2, var3, var4, var5) GCPRO5(var1, var2, var3, var4, var5)
+#if 0
#define GCPRO1(var1) ((void) ( \
gcpro1.next = gcprolist, gcpro1.var = &var1, gcpro1.nvars = 1, \
gcprolist = &gcpro1 ))
＠＠ -2046,6 +2065,7 ＠＠
nngcpro4.next = &nngcpro3, nngcpro4.var = &var4, nngcpro4.nvars = 1, \
nngcpro5.next = &nngcpro4, nngcpro5.var = &var5, nngcpro5.nvars = 1, \
gcprolist = &nngcpro5 ))
+#endif
#define NNUNGCPRO ((void) (gcprolist = nngcpro1.next))
--
Yoshiki Hayashi
8550
days inactive
8555
days old
1 comments
2 participants
tags (0)
participants (2)
-
Gunnar Evermann -
Yoshiki Hayashi