Hello, So I investigated a little bit with GDB and found that the crash happens on the val_callEx line... My program receives a SIGABRT...
Does someone have any idea about what could be wrong? Regards, On Thu, Mar 19, 2009 at 12:15 PM, Adrian Veith <[email protected]> wrote: > if you look at the neko vm code, the only thing that could go wrong > allocating a vm, is the call to alloc. Since alloc calls boehm gc, it > might be, that some garbage memory is freed, which might cause the > problem. Maybe you access freed memory. > > If your code crashes randomly, it is likely, that it is a memory and/or > stack issue. Create a test case and use a debugger to isolate the problem. > > Cheers, > Adrian. > > Benjamin Dasnois schrieb: >> Yes but if you look at one of my precedent post on the haXe list, >> allocating a new vm created the same kind of problem... :-/ I'm quite >> stuck... >> >> Regards, >> >> On Thu, Mar 19, 2009 at 7:53 AM, Adrian Veith <[email protected]> wrote: >> >>> Ok, maybe this is the problem. When I started with my code, I thought it >>> is better to keep a vm. I got several problems - one of them is the >>> stack. When a vm is allocated, a stack window is calculated from the >>> position of the vm var on the stack at creation time down to the maximum >>> stack size for the vm. If you have many calls between the allocation of >>> the vm and a call to valCallEx, it might happen, that valCallEx will >>> fail, because at the time of the call your stack is below the window. >>> >>> Now I changed my way of working. I create a vm before I call any neko >>> code (creating a vm is only a low overhead, and doesn't slow your code >>> much) and my problems are gone. >>> >>> Cheers, >>> Adrian. >>> >>> Benjamin Dasnois schrieb: >>> >>>> Well by default the limit is indeed 8MB which should be enough I >>>> think... Anyway, even making it up to 64MB (the maximum allowed by the >>>> default Darwin kernel) doesn't solve the problem.... >>>> >>>> Is there some function that I should call when I don't need a VM anymore? >>>> >>>> Regards, >>>> >>>> On Wed, Mar 18, 2009 at 4:43 PM, Benjamin Dasnois >>>> <[email protected]> wrote: >>>> >>>> >>>>> Hello Adrian, >>>>> >>>>> I don't think it's a problem with the stack size since a call to >>>>> ulimit in bash returns "unlimited"... >>>>> >>>>> But I'm going to investigate more in this direction. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> On Wed, Mar 18, 2009 at 4:30 PM, Adrian Veith <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> Benjamin Dasnois schrieb: >>>>>> >>>>>> >>>>>>> Following my project to create a bridge from FUSE to haXe, I still >>>>>>> have a problem : when my C callback is called and in turns calls the >>>>>>> haXe/Neko code it works as expected but if the C callback is fired >>>>>>> many times quickly, the call to the haXe/Neko code fails... >>>>>>> >>>>>>> Is it a known issue? >>>>>>> >>>>>>> >>>>>>> >>>>>> can you be more precise, where it fails ? >>>>>> >>>>>> I have a project running, where I call neko code from my delphi code and >>>>>> vice versa many times in a multi threaded server (I use neko .n modules >>>>>> as plugins in my server and the .n modules call again delphi code for >>>>>> some calculations). The only problem I had, is when the stack is low at >>>>>> generation of the vm, that the subsequent call to vallCallEx will fail. >>>>>> I use now a minimum stack size of 2MB and the code runs stable. >>>>>> >>>>>> >>>>>> hope that helps. >>>>>> >>>>>> Adrian. >>>>>> >>>>>> -- >>>>>> Neko : One VM to run them all >>>>>> (http://nekovm.org) >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> DASNOIS Benjamin >>>>> http://www.benjamindasnois.com >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> -- >>> Neko : One VM to run them all >>> (http://nekovm.org) >>> >>> >> >> >> >> > > -- > Neko : One VM to run them all > (http://nekovm.org) > -- DASNOIS Benjamin http://www.benjamindasnois.com -- Neko : One VM to run them all (http://nekovm.org)
