Menu
▾
▴
clisp-devel
|
From: Jerry J. <log...@gm...> - 2011-06-23 22:59:08
Attachments:
clisp-libsvm.patch
|
Hello all,
A few months ago, I assumed maintainership of the clisp package in
Fedora (not that I'm any kind of expert, but because I didn't want it
to be dropped from the Fedora repository). This week, I was notified
that clisp is failing to build in Fedora Rawhide. We are building the
libsvm module. The immediate build problem is that Rawhide moved from
libsvm 3.0 to 3.1, which dropped the deprecated svm_destroy_model
function entirely. I'm attaching the patch I came up with to address
this problem. I am not confident that it is correct. I'd appreciate
somebody looking it over for me.
After applying that patch, I'm still getting a build failure, while
running the tests. I don't understand it. I'll attach the entire
build log (compressed, due to its size), but here are the last few
lines:
(LIST (SYSTEM::CHARSET-RANGE CHARSET:BASE64 #\+ #\+ 2)
(SYSTEM::CHARSET-RANGE CHARSET:BASE64 #\+ #\/ 10)
(SYSTEM::CHARSET-RANGE CHARSET:BASE64 #\A #\Z 2)
(SYSTEM::CHARSET-RANGE CHARSET:BASE64 (CODE-CHAR 0) (CODE-CHAR 10000)
1000))
EQUAL-OK: ("++" "++//" "AZ" "++/9AZaz")
(LET ((LIST NIL)) (DO-EXTERNAL-SYMBOLS (SYM (FIND-PACKAGE "CHARSET"))
(PUSH (LIST SYM (ASH (LENGTH (SYSTEM::GET-CHARSET-RANGE
(ENCODING-CHARSET (SYMBOL-VALUE SYM)))) -1)) LIST)) (SETQ LIST (SORT
LIST #'< :KEY #'SECOND)) (FORMAT T "~& ~:D encoding~:P:~%~:{~25@A:
~5:D~%~}" (LENGTH LIST) LIST))
*** - handle_fault error2 ! address = 0x0 not in [0x333de6000,0x3340cd7d0) !
SIGSEGV cannot be cured. Fault address = 0x0.
GC count: 136
Space collected by GC: 127282680
Run time: 16 312519
Real time: 17 295187
GC time: 1 294797
Permanently allocated: 158312 bytes.
Currently in use: 6606296 bytes.
Free space: 485928 bytes.
make[1]: *** [tests] Segmentation fault (core dumped)
make[1]: Leaving directory
`/home/jamesjer/rpmbuild/BUILD/clisp-2.49/build/tests'
make: *** [check-tests] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Hve8lV (%build)
The previous build of clisp 2.49 didn't hit this, so I suspect another
environmental change of some kind. Any tips on tracking it down would
be much appreciated.
Also, in that build log, I see a number of messages of this form, all
for symbols in either libreadline or libdbus. Do these indicate that
those two modules have failed to build properly?
WARNING: FFI::FIND-FOREIGN-FUNCTION: foreign function "rl_set_prompt" does not
exist
Skip foreign function creation
Thanks, and regards,
--
Jerry James
http://www.jamezone.org/
|
|
From: Sam S. <sd...@gn...> - 2011-06-24 20:20:09
|
Hi,
> * Jerry James <ybt...@tz...> [2011-06-23 16:58:59 -0600]:
>
> A few months ago, I assumed maintainership of the clisp package in
> Fedora (not that I'm any kind of expert, but because I didn't want it
> to be dropped from the Fedora repository).
thanks!
> The immediate build problem is that Rawhide moved from libsvm 3.0 to
> 3.1, which dropped the deprecated svm_destroy_model function entirely.
> I'm attaching the patch I came up with to address this problem. I am
> not confident that it is correct. I'd appreciate somebody looking it
> over for me.
Thanks for the nice patch. However, I committed a different one because
I want to preserve support for libsvm 2.*.
Please try hg tip.
> (LET ((LIST NIL)) (DO-EXTERNAL-SYMBOLS (SYM (FIND-PACKAGE "CHARSET"))
> (PUSH (LIST SYM (ASH (LENGTH (SYSTEM::GET-CHARSET-RANGE
> (ENCODING-CHARSET (SYMBOL-VALUE SYM)))) -1)) LIST)) (SETQ LIST (SORT
> LIST #'< :KEY #'SECOND)) (FORMAT T "~& ~:D encoding~:P:~%~:{~25@A:
> ~5:D~%~}" (LENGTH LIST) LIST))
>
> *** - handle_fault error2 ! address = 0x0 not in [0x333de6000,0x3340cd7d0) !
> SIGSEGV cannot be cured. Fault address = 0x0.
> GC count: 136
> Space collected by GC: 127282680
> Run time: 16 312519
> Real time: 17 295187
> GC time: 1 294797
> Permanently allocated: 158312 bytes.
> Currently in use: 6606296 bytes.
> Free space: 485928 bytes.
> make[1]: *** [tests] Segmentation fault (core dumped)
> make[1]: Leaving directory
> `/home/jamesjer/rpmbuild/BUILD/clisp-2.49/build/tests'
> make: *** [check-tests] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.Hve8lV (%build)
please paste the failing form into clisp and see what happens.
I see this:
$ ./build/clisp -q -norc
[1]> (let ((list ()))
(do-external-symbols (sym (find-package "CHARSET"))
(push (list sym (ash (length (sys::get-charset-range
(encoding-charset (symbol-value sym))))
-1))
list))
(setq list (sort list #'< :key #'second))
(format t "~& ~:D encoding~:P:~%~:{~25@A: ~5:D~%~}" (length list) list))
117 encodings:
UCS-2: 1
UCS-4: 1
JAVA: 1
UNICODE-32-BIG-ENDIAN: 1
UNICODE-16-LITTLE-ENDIAN: 1
UNICODE-16: 1
UNICODE-32-LITTLE-ENDIAN: 1
UNICODE-32: 1
UNICODE-16-BIG-ENDIAN: 1
ISO-8859-1: 1
UTF-8: 1
UTF-7: 1
ASCII: 1
GB18030: 2
UTF-16: 2
BASE64: 4
TIS-620: 4
JIS_X0201: 6
ISO-8859-9: 8
ISO-8859-5: 8
ISO-8859-6: 8
ISO-8859-8: 9
CP874-IBM: 9
CP874: 10
ARMSCII-8: 10
ISO-8859-15: 12
HP-ROMAN8: 17
CP1252: 18
ISO-8859-7: 18
WINDOWS-1252: 18
MAC-THAI: 18
GEORGIAN-ACADEMY: 21
GEORGIAN-PS: 21
CP1254: 23
CP1133: 23
CP1253: 23
WINDOWS-1253: 23
WINDOWS-1254: 23
CP1251: 24
WINDOWS-1251: 24
MAC-HEBREW: 25
ISO-8859-14: 25
VISCII: 26
ISO-8859-3: 29
MAC-DINGBAT: 30
MAC-CYRILLIC: 31
MAC-UKRAINE: 31
CP850: 31
KOI8-R: 32
CP1255: 34
CP737: 34
ISO-8859-16: 34
WINDOWS-1255: 34
CP866: 34
CP857: 35
MAC-ICELAND: 35
ISO-8859-10: 36
MAC-ARABIC: 37
CP855: 38
MAC-GREEK: 39
CP869-IBM: 40
ISO-8859-4: 40
ISO-8859-13: 40
MAC-ROMAN: 41
MACINTOSH: 41
MAC-TURKISH: 41
CP869: 42
KOI8-U: 43
CP1256: 44
WINDOWS-1256: 44
ISO-8859-2: 45
MAC-CROATIAN: 45
MAC-ROMANIA: 46
CP1257: 47
WINDOWS-1257: 47
TCVN: 52
CP1250: 55
WINDOWS-1250: 55
CP860-IBM: 57
CP862-IBM: 57
CP862: 57
CP860: 57
MAC-CENTRAL-EUROPE: 59
CP437-IBM: 59
CP437: 59
CP865: 60
CP865-IBM: 60
CP863: 60
CP1258: 61
WINDOWS-1258: 61
CP863-IBM: 62
MAC-SYMBOL: 64
CP861-IBM: 64
CP861: 64
CP775: 69
CP852: 73
CP852-IBM: 74
CP864: 82
CP864-IBM: 82
GBK: 140
CP936: 140
CP949: 3,389
JOHAB: 3,391
EUC-CN: 3,632
CP950: 3,806
BIG5: 3,806
ISO-2022-CN: 3,906
ISO-2022-JP: 4,125
SHIFT-JIS: 4,127
CP932: 4,253
EUC-JP: 4,315
BIG5-HKSCS: 4,800
ISO-2022-KR: 5,001
EUC-KR: 5,002
ISO-2022-JP-2: 5,847
ISO-2022-CN-EXT: 6,450
EUC-TW: 6,690
NIL
[2]>
this test counts gaps in the range of different encodings.
if you get a crash, please rebuild --with-debug
(http://www.clisp.org/impnotes/faq.html#faq-debug)
and run under gdb and see what crashes, why and were and on which
encoding.
> Also, in that build log, I see a number of messages of this form, all
> for symbols in either libreadline or libdbus. Do these indicate that
> those two modules have failed to build properly?
>
> WARNING: FFI::FIND-FOREIGN-FUNCTION: foreign function "rl_set_prompt" does not
> exist
> Skip foreign function creation
this means that rl_set_prompt is not available in your libreadline.
what does
$ grep rl_set_prompt /usr/include/readline/readline.h
say?
--
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://dhimmi.com http://openvotingconsortium.org http://ffii.org
http://camera.org http://honestreporting.com http://iris.org.il
Things that cannot be programmed in assembler have to be soldered.
|
|
From: Jerry J. <log...@gm...> - 2011-06-24 22:59:39
|
On Fri, Jun 24, 2011 at 2:19 PM, Sam Steingold <sd...@gn...> wrote:
> Thanks for the nice patch. However, I committed a different one because
> I want to preserve support for libsvm 2.*.
> Please try hg tip.
Okay, I'll try to do that this weekend.
> please paste the failing form into clisp and see what happens.
> I see this:
This is interesting. I get the same crash from the already-built
clisp binaries on both Fedora 15 and Fedora Rawhide. Somehow those
binaries were built without the crash happening at build time, though.
After buildilng with debug turned on, here's the first part of the
backtrace:
(gdb) bt
#0 0x00007fffef5b5bf8 in to_gb18030 (irreversible=0x7ffffffedd00,
outend=0x7ffffffedfd8 "", outptrp=read_sleb128: Corrupted DWARF expression.
) at ../iconv/loop.c:332
#1 gconv (step=0x900eb0, data=0x900900, inptrp=0x7ffffffedf10,
inend=0x7ffffffedea4 "\003", outbufstart=0x0, irreversible=0x7ffffffede00,
do_flush=0, consume_incomplete=0) at ../iconv/skeleton.c:615
#2 0x00000037852224f4 in __gconv (cd=0x9008f0, inbuf=0x7ffffffedf10,
inbufend=0x7ffffffedea4 "\003", outbuf=0x7ffffffedf18,
outbufend=<optimized out>, irreversible=0x7ffffffede00) at gconv.c:80
#3 0x0000003785221b0a in iconv (cd=<optimized out>, inbuf=0x7ffffffedf10,
inbytesleft=0x7ffffffedf08, outbuf=0x7ffffffedf18,
outbytesleft=0x7ffffffedf20) at iconv.c:53
#4 0x00000000004a9188 in iconv_range (encoding=..., start=0, end=1114111,
maxintervals=4294967295) at ../src/stream.d:4416
#5 0x0000000000476906 in C_charset_range () at ../src/encoding.d:2179
#6 0x0000000000453c77 in funcall_subr (fun=..., args_on_stack=4)
at ../src/eval.d:5227
Hmmmmm, and we got a new glibc on June 3 (Fedora 15) / June 7
(Rawhide). It looks like there might be something wrong with the new
one. If I can come up with some C code that produces the same crash,
I'll file a bug report.
> this means that rl_set_prompt is not available in your libreadline.
> what does
> $ grep rl_set_prompt /usr/include/readline/readline.h
> say?
I think I see what's going on here. I attempted to build against
readline 5 to avoid the license problems with linking clisp against
readline 6. It appears I bungled the job. I'll try again.
Thanks for your reply.
--
Jerry James
http://www.jamezone.org/
|
|
From: Jerry J. <log...@gm...> - 2011-06-24 23:16:22
|
On Fri, Jun 24, 2011 at 4:56 PM, Jerry James <log...@gm...> wrote: > Hmmmmm, and we got a new glibc on June 3 (Fedora 15) / June 7 > (Rawhide). It looks like there might be something wrong with the new > one. If I can come up with some C code that produces the same crash, > I'll file a bug report. And here comes a new glibc through Fedora updates, and the Changelog includes this bit: - Repair GB18030 charmap (#712901) Looks like I need to try building again now. :-) Sorry for the noise. Regards, -- Jerry James http://www.jamezone.org/ |
|
From: Jerry J. <log...@gm...> - 2011-07-02 18:06:33
Attachments:
clisp-volatile.patch
|
On Fri, Jun 24, 2011 at 4:56 PM, Jerry James <log...@gm...> wrote: > Okay, I'll try to do that this weekend. Sorry, had to go on a trip, and I left town before finding time to do this. Your patch works great. Thank you. And Fedora fixed the glibc issue (a damaged gb18030 character table), so I've got a new build going now. While I was hunting for the source of the build failure, I looked through the build logs for clisp, and found a number of warnings from gcc about variables that might be clobbered by a longjmp(). That ultimately proved to not be the problem. However, I'm attaching the patch I made at that time to quiet the gcc warnings. Whether this patch prevents any actual problems from occurring will have to be decided by someone who knows the clisp code base. Regards, -- Jerry James http://www.jamezone.org/ |
|
From: Sam S. <sd...@gn...> - 2011-07-05 14:44:10
|
> * Jerry James <ybt...@tz...> [2011-07-02 12:06:25 -0600]:
>
> I looked through the build logs for clisp, and found a number of
> warnings from gcc about variables that might be clobbered by a
> longjmp(). That ultimately proved to not be the problem. However,
> I'm attaching the patch I made at that time to quiet the gcc warnings.
> Whether this patch prevents any actual problems from occurring will
> have to be decided by someone who knows the clisp code base.
Hi Jerry,
while I would love to see the ignorable warning disappear, I am a little
bit wary of using this patch because it seems that this abuses
`volatile' (its meaning is that "this variable can be modified outside
this process" which is not the same as what the warning is about).
--- src/control.d 19 Nov 2009 21:18:36 -0000 1.171
+++ src/control.d 2 Jul 2011 17:56:35 -0000
@@ -1593,7 +1593,7 @@
LISPSPECFORM(tagbody, 0,0,body)
{ /* (TAGBODY {tag | statement}), CLTL p. 130 */
- var object body = popSTACK();
+ var volatile object body = popSTACK();
{ /* build GENV-frame: */
var gcv_object_t* top_of_frame = STACK; /* pointer to frame */
pushSTACK(aktenv.go_env);
Bruno, WDYT?
--
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://pmw.org.il http://thereligionofpeace.com http://palestinefacts.org
http://www.PetitionOnline.com/tap12009/ http://openvotingconsortium.org
The difference between genius and stupidity is that genius has its limits.
|
|
From: Bruno H. <br...@cl...> - 2011-07-05 21:52:49
|
Sam wrote:
> --- src/control.d 19 Nov 2009 21:18:36 -0000 1.171
> +++ src/control.d 2 Jul 2011 17:56:35 -0000
> @@ -1593,7 +1593,7 @@
>
> LISPSPECFORM(tagbody, 0,0,body)
> { /* (TAGBODY {tag | statement}), CLTL p. 130 */
> - var object body = popSTACK();
> + var volatile object body = popSTACK();
> { /* build GENV-frame: */
> var gcv_object_t* top_of_frame = STACK; /* pointer to frame */
> pushSTACK(aktenv.go_env);
My opinion has always been that if a compiler issues a pointless warning,
I ignore this warning, rather than making changes that slow down the program
and remove the warning.
Here the warning is pointless because the dangerous situation with setjmp()
is that when it returns a nonzero value, the register-allocated local
variables may have been clobbered (an effect typically only seen on SPARC
CPUs, but I'm glad gcc warns about it on all platforms). Here the only
setjmp() call is in the
finish_entry_frame(ITAGBODY,returner,, goto go_entry; );
line, and when setjmp() has returned a nonzero value, the statement
body = value1;
is executed.
> while I would love to see the ignorable warning disappear, I am a little
> bit wary of using this patch because it seems that this abuses
> `volatile' (its meaning is that "this variable can be modified outside
> this process" which is not the same as what the warning is about).
'volatile' instructs the compiler not to make assumptions about the variable's
value. If it removes the warning then - apparently - because it also causes
gcc to allocate the variable on the C stack rather than in a register.
So, it slows down the interpreter.
Bruno
|
|
From: Sam S. <sd...@gn...> - 2011-07-05 22:07:36
|
> * Bruno Haible <oe...@py...> [2011-07-05 23:27:04 +0200]: > > Here the warning is pointless because the dangerous situation with setjmp() > is that when it returns a nonzero value, the register-allocated local > variables may have been clobbered (an effect typically only seen on SPARC > CPUs, but I'm glad gcc warns about it on all platforms). Here the only > setjmp() call is in the > finish_entry_frame(ITAGBODY,returner,, goto go_entry; ); > line, and when setjmp() has returned a nonzero value, the statement > body = value1; > is executed. ok, so this warning is a gcc bug. Jerry, could you please file a gcc bug report? thanks! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://honestreporting.com http://www.PetitionOnline.com/tap12009/ http://ffii.org http://palestinefacts.org http://pmw.org.il http://memri.org Never succeed from the first try - if you do, nobody will think it was hard. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X