Crashing stable and development version on 64bit platform

[karijes]

Hi,



Sorry for posting on forum, but is there a bug tracker for reporting bugs or what are practices for reporting issues? I found odd crashes in both stable (10.5.4) and development versions (10.5.6) when they gets compiled with makefile_linuxLP64_utf8_ffi. I'm running it on Slackware 14.1 64bit.



By running in REPL this:

Code Select Expand


> (:button 32)

it will crash both mentioned interpreters. This is the stacktrace:

Code Select Expand


Program received signal SIGSEGV, Segmentation fault.
0x00000000004096da in printCell (cell=0x20, printFlag=1, device=6700736) at newlisp.c:2514
2514    switch(cell->type)
(gdb) bt
#0  0x00000000004096da in printCell (cell=0x20, printFlag=1, device=6700736) at newlisp.c:2514
#1  0x000000000040b1c0 in printErrorMessage (errorNumber=15, expr=0x20, deleteFlag=0) at newlisp.c:3149
#2  0x000000000040aff4 in fatalError (errorNumber=15, expr=0x20, deleteFlag=0) at newlisp.c:3112
#3  0x000000000040aef6 in errorProcAll (errorNumber=15, expr=0x20, deleteFlag=0) at newlisp.c:3080
#4  0x000000000040af5f in errorProcExt (errorNumber=15, expr=0x20) at newlisp.c:3093
#5  0x00000000004147b2 in p_colon (params=0x7ffff7f33010) at newlisp.c:7185
#6  0x00000000004073a8 in evaluateExpression (cell=0x7ffff7f36350) at newlisp.c:1510
#7  0x0000000000406630 in evaluateStream (stream=0x7fffffffda80, outDevice=2, flag=0) at newlisp.c:1283
#8  0x0000000000406461 in executeCommandLine (command=0x6c12e0 "(:button 32)", outDevice=2, cmdStream=0x7fffffffdaf0) at newlisp.c:1230
#9  0x00000000004056d5 in main (argc=1, argv=0x7fffffffe028) at newlisp.c:901

:button wasn't declared anywhere, so it is nonexisting symbol. Any idea what could go wrong?

[rickyboy]

Yes, this is the right place to post bugs.  (There's no separate bug tracker.)



BTW, I get a segfault doing the same thing on 10.5.3 on my Mac; so this issue has probably been sneaking around for a while unnoticed.



Lutz will undoubtedly look into this and respond here.  Thanks for pointing this out!

[Lutz]

Only seems to occur on 64-bit compiles and is fixed now in:



http://www.newlisp.org/downloads/development/inprogress/newlisp-js-10.5.7.zip">http://www.newlisp.org/downloads/develo ... 10.5.7.zip">http://www.newlisp.org/downloads/development/inprogress/newlisp-js-10.5.7.zip



in the p_colon() function in newlisp.c. Thanks for the stack trace which was helpful in fixing this.



Like rickyboy says, bugs are normally reported right here on the forum under any category and fixed as soon as possible. Normally each release is without known bugs, if not, it is mentioned in the release notes or the documentation (there are some unsafe functions, e.g.: cpymem). Fixes are mentioned in the release notes and very minor fixes in the CHANGES notes.

[karijes]

Thanks guys for pointers; and thanks Lutz for quick fix.



Btw. I noticed another issue: in makefiles marked as makefile_linux_*_ffi is missing -lffi for Slackware and other distros than Ubuntu.

[Lutz]

On each Linux distribution the install location of libffi is different. For development I am only running UBUNTU 32-bit. If you have the standard location for libffi on Slackware, I can add that information to the makefile. We need also to update the -I/ include path in the CFLAGS.



Also, the -ltermcap and -lncurses specs are pretty old. I wonder if we still need them on Slackware and other Linux when -lreadline is present.



On the UTF8 configuration issue:

I would love to standardize all binary distributions on UTF8. Mac OS X already ships only UTF8 and it makes sense as the whole OS environment is tuned to this. We should be able to do the same for Linux?



On Windows I tried once, but had to undo that change quickly. Filesystem names seem to be standardized on UTF16. But utilities like notepad.exe are still on one-byte ISO-8859-1 and the old Windows-1252?



As everybody, even the non-web programmer, has to manipulate UTF8 text today wouldn't it make sense to standardize on that. Only about 15% of Windows package downloade also download http://www.newlisp.org/downloads/UTF-8_win32/newlisp.exe">http://www.newlisp.org/downloads/UTF-8_ ... ewlisp.exe">http://www.newlisp.org/downloads/UTF-8_win32/newlisp.exe, but I wonder if all could go with UTF8?

[TedWalther]

I think all Linux out there today support UTF8 well.  I guess the Windows guys will have to add a couple more lines of code to translate UTF-8 to UTF-16 or ASCII.



As for the -ltermcap -lncurses flags, find out by running configure-alt; I designed it to autodetect that.



How much more work is needed to make configure-alt the default configure?  I'd have updated it to subsume all your makefiles, but I don't have access to all the platforms you have access to.

[Lutz]

The main thing missing is detection of libffi, everything else looks pretty good:



Mac OS X:

libffi support should always be enabled, comes standard on Mac OS X



UBUNTU Linux:

user must install in standard location



I am currently using /usr/local/lib/libffi.a as the linked library and /usr/local/lib/libffi-3.0.13/include as an added include path



Perhaps both can be detected by configure?



see: makefile_linux_utf8_ffi



FreeBSD

User must install libffi in standard location, I have no idea where that is, but know that it works when present. Tried on FreeBSD 9.2 installing libbfi in my home dir. Not sure where and how to look for it in configure.



Windows:

user must install libffi.a in MinGW/lib, the include file is part of the source distribution.



For all Unix like OS except Mac OS X:

What has to be looked for are: libffi.a and ffi.h and ffitarget.h on all Unix like OS.



On Windows only libffi.a, the include file for Windows comes (ffi.h and ffitarget.h together) in the newLISP source distribution and libffi.a must be installed in MinGW/lib. Not sure if the latest version of MinGW does include it.



The configure can make without, but should put out a warning similar to this:



"extended FFI" using libffi is not supported and must be installed,

the "simple FFI" is always present in newLISP"



I use the terms "simple FFI" and "extended FFI" throughout the documentation. The simple FFI is always present and doesn't need any special support. All standard modules, except for gsl.lsp, can be used with the simple one. But the extended one is a 'must' for gsl.lsp and many scientific computing libs using floats extensively.

[karijes]

Also, the -ltermcap and -lncurses specs are pretty old. I wonder if we still need them on Slackware and other Linux when -lreadline is present.

-ltermcap is still needed. I compiled the code without -lncurses.



Sorry for dumb questions, but I'm just curious why don't you rely on autoconf or cmake? They can simplify detection a lot, especially since you are targeting multiple platforms. Or do you target portable make? If not so, GNU make contains a bunch of advanced constructs like branching, evaluation, substitution and etc. which allows easier writing of more complex build code and can be done without autoconf or cmake.

[Lutz]

One of newLISP's goals is, to have as little external dependencies possible. newLISP is compiled frequently on smaller systems and sometimes without GNU tools.



The less dependencies and complexity the build process has, the less there is to install, the better it is understood and that makes it easier porting newLISP to new platforms.

[abaddon1234]

Thanks for the info

https://www.sbobet168.com/banking/">แจ้งฝากเงิน sbobet

[rickyboy]

Thanks for the info

https://www.sbobet168.com/banking/">แจ้งฝากเงิน sbobet

Thanks for hawking your douche-bag website.  Yeah, that's what we are *really* all here for -- and you figured it out.  We have been here for years pretending to be interested in newlisp, just hoping and praying that some douche-nozzle would come here and sell us chances at their on-line casino because we have nothing better to do here.