Test results for D on Android/ARM

[Joakim via digitalmars-d-ldc]

On Thursday, 12 November 2015 at 03:46:07 UTC, Jakob Ovrum wrote:
> On Sunday, 8 November 2015 at 09:49:18 UTC, Joakim wrote:
>> They're both related to accessing files, whether a socket file 
>> or a symbolic link.  Given that they pass from the apk, my 
>> guess is that this is related to user/file permissions because 
>> you're running as root from the Download directory.  Can you 
>> try running as a normal user in the local folder for SSHDroid, 
>> as described here?
>>
>> http://wiki.dlang.org/Build_LDC_for_Android#Run_the_druntime_and_phobos_unit_tests
>
> Running it as root in the home directory 
> (/data/data/berserker.android.apps.sshdroid/home) fixed those 
> errors. I don't know how to add non-root users though.

Unless you're running sshdroid as root, it should create a 
temporary user, like all Android apps, and run as that user, 
regardless of whether you used the login "root" or not.  I've 
found that the SSH login is irrelevant: you can type in any login 
for sshdroid and it will accept it, as long as it has the right 
password, which makes sense because it doesn't really create 
users of its own.

So you should have been running as the app's user in it's 
directory, just as I wanted.  I'm uninterested in debugging the 
user/file permissions issues that come with running elsewhere, 
especially since that's not allowed unless you're root, ie you 
can't normally run binaries from the Download/ directory.

>> With some builds, I used to get an issue with core.thread 
>> interacting with the static destructor for std.parallelism, 
>> which would cause a segfault on exit.  This could be that 
>> issue.
>>
>> As for debugging, the NDK comes with an ARM gdb server, found 
>> in prebuilt/android-arm/gdbserver/gdbserver, which you can use 
>> with their gdb to remotely debug Android apps.
>
> Thanks, I got gdb-server running. In core.thread and some later 
> modules it stops because of SIGUSR1 and SIGUSR2; I guess I 
> should make gdb ignore those?

Yes, there's a gdb command for it:

handle SIGUSR1 SIGUSR2 nostop

You can also add "noprint," if you don't even want to be notified 
that those signals were sent.

> After continuing from all the SIGUSR signals, I get the 
> segfault that occurs after std.internal.math.gammafunction 
> passes:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 22658.22658]
> 0x4250a364 in core.thread.Thread.getAll() ()
> (gdb) bt
> #0  0x4250a364 in core.thread.Thread.getAll() ()
> #1  0x43236e04 in std.parallelism._sharedStaticDtor7() ()
> #2  0x42549758 in rt.minfo.rt_moduleDtor() ()
> #3  0x42557e70 in rt_term ()
> #4  0x42558120 in _d_run_main ()
> #5  0x43e85418 in ?? ()
> Backtrace stopped: previous frame identical to this frame 
> (corrupt stack?)
> (gdb) info threads
>   Id   Target Id         Frame
> * 1    Thread 22658.22658 0x4250a364 in 
> core.thread.Thread.getAll() ()
>
> I'm guessing this is the same issue you mentioned.

Yep, that's it.  Guessing it's some sort of race on exit, since 
it doesn't always happen.  You can remove core.thread from 
test.list to confirm that it's the same reason.