On 9/9/19, PR polos.ruetz@gmail.com wrote:

never mind, asking around helped (this branch is not cleaned-up, as the author says, but surely a very good start for somebody willing to pick up from there):

https://gitlab.com/embeddable-common-lisp/ecl/blob/arm64-port/ios_build.md

ok, so having a working build script for ECL on iOS arm64 is a big step forward, but still not enough: I have no problem compiling and deploying the "arm64-port" branch with the following versions:

Xcode 10.2 iOS 12 (phone)

But it crashes with EXC_BAD_ACCESS during cl_boot(). I can't currently be precise about the point/function it crashes, because this depends on what I put in the main() function: if I add some arbitrary stack variable before cl_boot(), like:

char tmp[256]; cl_boot(1, argv);

it crashes at a completely different point than without it, the same if I simply change the size of the char vector. The author of the above branch was able to run it successfully about 3 years ago (2016), even with ASDF and Swank, on a real device.

Now my question is: if you tried it, and it worked for you, what were the exact Xcode and iOS versions you used?

Thanks,

Paul

On 9/18/19, Gunter Königsmann gunter@peterpall.de wrote:

Would it be possible for you to provide backtraces for a few different crashes?

Thanks for your input, now let me explain better:

A few days ago I tested with a little different configuration, and the backtrace was just a few frames. Some 'cl_object' pointer had a too low address, and this caused an EXC_BAD_ACCESS some frame after function 'si_pathname_translations()'.

What currently happens (witch Xcode 10.2 and the exact same 'arm64-port' branch as on gitlab) is that the backtrace is very long, always exactly 6780 frames; I thought of a blown stack, and didn't look at the highest frames, which indeed point always to the same function; the error condition happens (as above) inside of function 'si_pathname_translations()'.

Attached you find the full backtrace; at the end I added a short lldb session, printing some variables. Here the most interesting lines from the lldb session:

frame #6777: 0x0000000100cd6c88 repl`si_pathname_translations(narg=2, host=0x000000010250bfc0) at pathname.d:1555:34 1552 for (l = set, set = ECL_NIL; !ecl_endp(l); l = CDR(l)) { 1553 cl_object item = CAR(l); 1554 cl_object from = coerce_to_from_pathname(cl_car(item), host); -> 1555 cl_object to = cl_pathname(cl_cadr(item)); 1556 set = CONS(CONS(from, CONS(to, ECL_NIL)), set); 1557 } 1558 set = cl_nreverse(set);

(lldb) print item (cl_object) $0 = 0x00000001013c1931

(lldb) print from (cl_object) $1 = 0x00000000000000db

(lldb) print to (cl_object) $2 = 0x0000000100f08a98

As you can see, the value of the 'from' pointer is way too low for a valid 'cl_object' pointer address.

(to be continued...)

Dear Paul,

unfortunately, I don't have time at the moment to look at this in detail, however already from the second backtrace of yours I see that something is missing. Between

frame #4: 0x0000000100437940 repl`cl_M(narg=1, num=0x0000000000000001) at minus.d:26:23

and

frame #5: 0x000000010052cc44 repl`::_ecllqJxvfb7_PZJOlV41(flag=0x0000000000000000) at numlib.cxx:882:10

I would have expected to see a call to the dispatch_variadic_1 function. Can you please confirm that USE_C_COMPATIBLE_VARIADIC_DISPATCH is defined while compiling src/c/cfun.d, e.g. by inserting

#ifndef USE_C_COMPATIBLE_VARIADIC_DISPATCH #error "undefined" #endif

in the file and recompiling and that (ECL_SYM("-",17)->symbol.gfdef)->cfun.entry points to the dispatch_variadic_1 function?

All the stuff below that in the backtrace is not relevant.

Best regards, Marius

Am 20.09.19 um 11:08 schrieb PR:

On 9/19/19, PR polos.ruetz@gmail.com wrote:

...

On 9/18/19, Gunter Königsmann gunter@peterpall.de wrote:

...

Would it be possible for you to provide backtraces for a few different crashes?

(to be continued...)

Here another backtrace. I just commented out the following lines in 'cl_boot' (on the desktop I discovered that they are not necessary for simply starting up ECL):

file 'src/c/main.d', lines 672-678:

/*

• Initialize logical pathname translations. This must come after
• the character database has been filled.

*/ //@si::pathname-translations(2,str_sys, // ecl_list1(cl_list(2,str_star_dot_star, // str_rel_star_dot_star)));

Now the backtrace is only 12 frames long (see attachment). Still no clue what's going on...

On 9/23/19, PR polos.ruetz@gmail.com wrote:

On 9/21/19, Marius Gerbershagen marius.gerbershagen@gmail.com wrote:

...

[...]

So, ECL starts up without problems now, but there is an (apparently) known issue with GC. The app crashes, seemingly during the first cycle of GC, see attached backtrace.

But I noticed these lines in the 'ecl-android' project (github) of old, which has also an 'iOS' directory with an example app. There you find these lines before 'cl_boot':

int argc = 1; char *argv[256]; argv[0] = "ecl"; GC_allow_register_threads(); GC_register_my_thread((const struct GC_stack_base *)argv); GC_stackbottom = (char*)(argv+255); // corrected to 'char*' (was: 'void*') setenv("ECLDIR", "", 1); cl_boot(argc, argv);

Now, if I put the above lines before 'cl_boot', the app works.

Does anybody know why this is needed, and what it is doing? Because if my Lisp app grows (I tried to include :cl-ppcre), then the app crashes again, despite the above hack (and with the same backtrace of the attachment).

Of course I already tried bigger vector sizes (up to 8192) instead of 256, but that doesn't solve it.

What else could I try?

Thanks,

Paul

On 9/26/19, some <nobody> wrote: [...]

...and if you were wondering if this got somewhere, here a practical link:

https://gitlab.com/eql/eql5-ios