Hi, I confirm it works now I recompile rumprun for xen with a fresh separated tree.
Thanks for the help ;-) On 21 June 2015 at 14:41, David CARLIER <[email protected]> wrote: > > > On 21 June 2015 at 14:35, Antti Kantee <[email protected]> wrote: > >> 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. >> >> > Yes indeed did compile both versions with same tree :-| > > > >> 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. >> > > Very good I ll try it soon thanks ;-) > >
