On 21 June 2015 at 13:40, Antti Kantee <[email protected]> wrote: > On 21/06/15 12:12, David CARLIER wrote: > >> Hi and thanks in advance for the help. >> >> I compiled a C code of my own with static version of PCRE library, then >> "baked" it. This C code needs a file input which i put inside an ISO. >> >> Then I used rumprun and had still trouble with qemu, had bunch of >> pagefault >> error issued. It is solved now but I have still trouble to launch via >> Linux/xen like this >> >> rumprun xen -d -i -b jsons.iso,/jsons -- app.bin.xen /jsons/sample.json >> >> Then I get an infinite page caller <address> ... displayed and after some >> minutes that hang, very hard to shut it down or even getting out of the >> console (Sorry in advance I never used Xen before so I m pretty ignorant). >> > > 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 :-)
> 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 ... > > Generally, I find debugging with the xen platform harder than debugging > with hw because gdbsx seems very temperamental. If you can repeat the > errors under qemu, it's easy to track them down. (nb. rumprun kvm is > horrible for debugging with gdb, but rumprun qemu works perfectly) > >
