Hi, you have to follow the call in assembler view and look where it crashes inside val_callEx - There are several possibilities. - BTW do you pass a pointer to a exc value ? - If not: you should change that.
Cheers, Adrian. Benjamin Dasnois schrieb: > 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) >> >> > > > > -- Neko : One VM to run them all (http://nekovm.org)
