Mark,

thanks.

> You should be able to chase the buffer overflow down fairly easily.
>
> *** buffer overflow detected ***: rexx terminated
> ======= Backtrace: =========
> /lib/libc.so.6(__fortify_fail+0x37)[0x7fb7374ee2c7]
> /lib/libc.so.6[0x7fb7374ec170]
> /lib/libc.so.6[0x7fb7374eb519]
> /lib/libc.so.6(_IO_default_xsputn+0x96)[0x7fb737465426]
> /lib/libc.so.6(_IO_vfprintf+0x348d)[0x7fb737437e2d]
> /lib/libc.so.6(__vsprintf_chk+0x99)[0x7fb7374eb5b9]
> /lib/libc.so.6(__sprintf_chk+0x80)[0x7fb7374eb500]
> /mnt/root_e/rony/dev/bsf/src/bsf4rexx/libBSF4Rexx.so(BSF_impl+0x348)[0x7fb734d90fb8]
>
> 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
>   
>>      rexx.dll!00337328()     
>>     
>       [Frames below may be incorrect and/or missing, no symbols loaded for
> rexx.dll]
>       rexx.dll!002ff218()     
>       rexx.dll!002e9490()     
>       rexx.dll!00303462()     
>       rexx.dll!003473c9()     
>       kernel32.dll!7c80b729()
>
> 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 
> code.
> 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.
>   
Again, thanks!

---rony
------------------------------------------------------------------------------
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to