> You should be able to chase the buffer overflow down fairly easily.
> *** buffer overflow detected ***: rexx terminated
> ======= Backtrace: =========
> So it looks like in your BSF() function you are using sprintf() to
> format something
> into a buffer that is too small. Double your buffer size and see if
> it goes away.
> Or, better, look carefully and what you are formatting and figure out what is
> bigger than you are anticipating.
Yes, after having posted it and coming back from lunch I started to go
after that (it may be caused by debug output only).
> For this one:
> Scenario 1: 32-bit Windows (not tested on 64-bit Windows), exception
> in "rexx.exe":
> Here I may get the following exception
> [Frames below may be incorrect and/or missing, no symbols loaded for
> You're not going to get anywhere with this, you need to use a debug version
> of the interpreter and BSF so you can see what functions these are.
> If, you have a scenario that produces the exception 100% of the time with
> a non-debug build, and then never produces the exception with a debug
> version - well that's going to be hard. It also is very rare. But,
> if it is the case,
> you'll need to at least track the addresses down in the map file and use the
> *.asm files to see exactly where this sequence is.
> That means you'll need to build the intepreter yourself using the release
> The map files will be in Win32Rel and the *.asm files are in Win32Rel\ASM.
Thanks for this advice!
> If I were tackling this, I'd fix those 2 bugs first, in the order I
> listed, before even thinking about the third one.
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
Oorexx-devel mailing list