Thanks a lot for your help! Sorry that it happened to be my bug. It was a bug in gsl.fs word pvector. I should have set the value of owner explicitly to 0. I will send you the latest version of the library for inclusion when I will merge it with your changes.
The great thing is addition of the word func'. Now no need for any auxiliary functions - all can be written in bigforth. And it is indeed belongs in callbacks.fs The debugging advice is of great value too. Again documentation issue. traceall is not described in the manual (even in German). In any case, thank you for responsiveness and very fast fixing of issues. -- Sergey On Sunday 02 September 2007 14:37:40 Bernd Paysan wrote: > On Sunday 02 September 2007 21:10, Sergey Plis wrote: > > On Sunday 02 September 2007 11:16:00 Bernd Paysan wrote: > > > Duh, there's a word conflict between FREE for bigForth's own memory > > > handling and the Unix FREE. So you ALLOCATE from bigForth's memory > > > pool and you FREE from POSIX' memory pool. A crash is inevitable. > > > Changes checked in. > > > > Please find attached an archive with 3 files in it. In order to > > reproduce the bug I am having do: > > > > bigforth ode_example_fixed_interval.fs > > > > In gdb you'll see this: > > > > Program received signal SIGSEGV, Segmentation fault. > > gsl_block_free (b=0x64) at init_source.c:77 > > 77 init_source.c: No such file or directory. > > in init_source.c > > > > Bernd, I cc this to your personal address just in case the mailing > > list does not take my attachment. > > I received it only once, so the list probably refused the complete mail. > > I see that the gsl library contains symbols which should give you just a > pointer, and I've added a func' word to callback.fs (I think it's > appropriate there), which turns a library binding into the C function > pointer (i.e. the address inside the library). That should help you to > get access to those step types without creating and compiling a helper > library. I modified the use of your pointer library into straight > forward (int) declarations, and use func' <step type name> @ to get the > type. > > Further help to track down bugs: Insert a "traceall" into your source > somewhere before you suspect it to crash. This will output everything > that's interpreted before, even when the crash itself is corrupting the > system. > > Next thing: Insert ~~ into the program parts you suspect of crashing. > Each ~~ will print out the source location and the stack (and it works > even within a callback). With that, I've located the problem: > The "y[ ]free" in _func is causing the problem. Removing that one makes > your example run. There's no memory leak observable during the run, so > the other callback function takes care of freeing that memory. I'm not > sure if the result is right, but the result oscillates. > > BTW: For numerical stability in algorithms like that, don't increment > your floating point variable with a delta step (f:=f+deltaf), but > instead use an integer index, and multiply it with the delta step to > obtain the current position (f:=f0+i*deltaf). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
