[Ecls-list] Segmentation faults/detected access to ...address

[Seth Burleigh]

Oh, forgot to mention, Im on linux running ecl 10.3.1

The error is actually thrown by cl_safe_eval, not by c_string_to_object
(though i would think it would be thrown by c_string_to_object). Just to
be sure, I put it right before
cl_safe_eval(obj,(cl_object)env,Cnil) , same result.  Im guessing this
is related to the earlier topic about SIGINT in linux not being caught
in 10.3.1.

So i guess errors thrown by lisp code are segmentation faults if not
caught by the lisp code or by the CL_CATCH_ALL_IF_CAUGHT block? I was
taking a look at the (cl_object err_value) parameter of cl_safe_eval,
and was wondering that instead of segmenting it should've simply
returned Cnil to represent an error?
 



On Sat, 2010-03-13 at 17:23 +0100, Juan Jose Garcia-Ripoll wrote:
> I do not have time for a longer answer right now but note two things:
> 
> - Segmentation faults in arbitrary code can not be graciously handled
> by ECL. Instead it just looks for the outermost CATCH_ALL statement
> and jumps there. Since there is no such statement surrounding
> c_string_to_object(), it just quits.
> 
> - puts() accesses the content of its argument. if you use puts(obj ==
> OBJNULL) it is like using puts(1) which tries to access the memory
> location (char*)1 causing a segmentation fault or an access violation
> -- it depends on the OS.
> 
> Juanjo
> 
> On Sat, Mar 13, 2010 at 5:08 PM, Seth Burleigh <seth at tewebs.com>
> wrote:
>         So, i decided that I would try to get a c REPL going which
>         would also
>         catch any errors with incorrectly entered code (not go into
>         the
>         debugger). Cool stuff , ecl:)
>         Anyways, I found that whenever I entered an statement which
>         would
>         generate an error, like the letter a, the program exits with a
>         segmentation fault. Im not exactly sure why entering an
>         invalid
>         statement would generate one. I was also wondering if ecl was
>         supposed
>         to catch all segmentation faults which resuled from lisp code
>         executing
>         inside of it? According to this:
>         http://ecls.sourceforge.net/new-manual/re41.html
>         SIGSEGV should be caught automatically? I noticed that if i
>         used
>         cl_eval, everything would work, it would just go into the
>         debugger.
>         Also, I noticed that if i uncommented the code below it would
>         produce a
>         "Detected acccess to an invalid or protected memory address"
>         and would
>         throw me into the lisp debugger. I know this has something to
>         do with
>         'puts' expecting a constant char* while the statement
>         obj==OBJNULL
>         returns an int, but I would like to understand what exactly is
>         causing
>         this error.
>         
>         Heres the code:
>         
>         #include <ecl/ecl.h>
>         #include <stdio.h>
>         #include <string.h>
>         
>         int main(int argc, char **argv)  {
>          cl_boot(argc, argv);
>          cl_env_ptr env = ecl_process_env();
>          while (1) {
>            printf(">>");
>            int nbytes = 100;
>            char *str = (char*)malloc(nbytes);
>            getline(&str,&nbytes,stdin);
>            if (strcmp(str,"exit\n")==0 ) {
>              break;
>            }
>         
>            cl_object obj = c_string_to_object(str);
>         
>            //uncommented code below produced unprotected access error
>            //puts(obj==OBJNULL);
>         
>            CL_CATCH_ALL_BEGIN(env) {
>              cl_object evaled = cl_safe_eval(obj,(cl_object)env,Cnil);
>              cl_pprint(1,evaled);
>            } CL_CATCH_ALL_IF_CAUGHT {
>              puts("ERROR");
>            } CL_CATCH_ALL_END;
>          }
>          cl_shutdown();
>         }
>         
>         
>         
>         ------------------------------------------------------------------------------
>         Download Intel® Parallel Studio Eval
>         Try the new software tools for yourself. Speed compiling, find
>         bugs
>         proactively, and fine-tune applications for parallel
>         performance.
>         See why Intel Parallel Studio got high marks during beta.
>         http://p.sf.net/sfu/intel-sw-dev
>         _______________________________________________
>         Ecls-list mailing list
>         Ecls-list at lists.sourceforge.net
>         https://lists.sourceforge.net/lists/listinfo/ecls-list
> 
> 
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com