Re: Fwd: Launching C userland code with rumprun
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Sun, 21 Jun 2015 13:35:25 +0000
On 21/06/15 13:08, David CARLIER wrote:
You say it's C code of your own. Are you confident that it's correct? Did
you try running it as a normal userspace binary under valgrind? I often
find the most bugs in my own code ... ;)
Yes tested under lot of different oses, primarily Linux/valgrind but also
OpenBSD/MALLOC_STATS, FreeBSD/jemalloc etc etc there is no corrupted
pointer or nasty double free somewhere :-) Anyway that work very fine under
qemu I guess I did something wrong in the compilation chain for xen case (I
have compiled two different versions of PCRE one for qemu usage one for xen
then the library of this C code and in the end the executable, all
stoically compiled for each version). In fact I just try to understand how
all work before doing more complex use cases :-)
Ok, just trying to start from the most likely explanation, since I
didn't know if the code had been tested anywhere. You seem to trust
your code, so let's look elsewhere.
Are you compiling qemu and xen from two different rumprun source trees?
It's currently (unfortunately) not a good idea to use the same source
tree to build for multiple targets. It works if you know what you're
doing, but I cannot advise as good practice when trying to eliminate errors.
Can you copypaste the exact error message?
The error I get is infinite lines like this and that never stop
base is 0xccf848 caller is 0x109ab
base is 0xccf8f8 caller is 0x109ab
and so on ...
Ah. Well I just added a 100 frame limit to the stack walk. That should
give you information about the root cause of the problem without it
getting lost.
Pull, recompile, and try again. You can get info about caller by
loading the binary in qemu and typing "l *address", e.g.
gdb -ex "l *0x109ab" app.bin.xen
I'll put actual loop detection in the stack walk later and make it
generally better, but gotta run now.
Other related posts:
