Loader bug.

[joseluisquiroga]

Hello parallella comunity.

It seems there is a bug in the loader (e-loader.c). It seems that the 'mmap' function used internally by 'e_alloc' and used in the '_e_default_load_group' func during loading, return overlaping physical memory areas (in shared mem) while returning non overlaping virtual memory areas. Maybe you should never call "mmap(NULL ..." in parallella ?

For a concrete example:

https://github.com/joseluisquiroga/para ... lq-test-20

Observations:
1. Sorry I could not make it smaller because is very aleatoric when this overlaping happens.
2. Build with https://github.com/joseluisquiroga/para ... 0/build.sh
3. Run with https://github.com/joseluisquiroga/para ... -20/run.sh
4. File https://github.com/joseluisquiroga/para ... ader_znq.c
is a modification of the original loader to catch the error.


JLQ.

[joseluisquiroga]

A better example (still big) of the bug in:

https://github.com/joseluisquiroga/para ... lq-test-21

Observations:

1. It builds two epiphany core executables one that loads and runs and one that does not. It seems that size matters.
The one that fails just links one additional c file with constants that go to shared ram (not core ram). (https://github.com/joseluisquiroga/para ... est_logs.c)
2. Build with https://github.com/joseluisquiroga/para ... 1/build.sh
3. Make it fail with: https://github.com/joseluisquiroga/para ... /no_run.sh
4. Run it with: https://github.com/joseluisquiroga/para ... -21/run.sh

JLQ.

[joseluisquiroga]

An small example that shows the bug:

https://github.com/joseluisquiroga/para ... lq-test-22

It looks to me as a bug in the /dev/epiphany/mesh0 device because each byte written is checked at write time, and just after writing an array in shared mem, checking the written contents fails (they have been changed). Maybe some other process (OS ?) has used the reserved memory?

Anything? Anyone? Olajep? Comments, thoughts, opinions?

Any feedback is welcome.

JLQ.

[olajep]

[joseluisquiroga]

Thank you for answering Olajep !

Nope. There is a bug.

Now try this:
Run it first with e_load_group and THEN WITHOUT it (just as posted) and it ALSO PASSES.

It is the same as uncommenting the memcpy call in my code runnning it and then commenting it again in line

https://github.com/joseluisquiroga/para ... znq.c#L659

So running memcpy FISRT CHANGES something in the OS that then my code AS POSTED passes the assert !!

There is a bug.

JLQ.

[joseluisquiroga]

You can also try adding the mem check assert after line 517 in the original in e_loader.c:

https://github.com/adapteva/epiphany-li ... der.c#L517

And try to load the ephiphany executable I provided (It has to be that one) because the bug is very aleatoric.

It will fail.

JLQ.

[olajep]

[olajep]

[joseluisquiroga]

Sorry man.

By now I think you already know there is a bug in /dev/epiphany/mesh0 :

https://github.com/parallella/parallell ... epiphany.c

I will bet I am not the only one pointing to that. It seems a nasty ugly bug. Maybe design bug. Shared memory is NOT insulated from other processes.

The problem is not in bj_load_group nor in e_load_group is in the driver of /dev/epiphany/mesh0 so good luck.

I cannot help you with that.

JLQ.

[olajep]