OpenEuphoria

1. ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 17, 2008
• 1118 views

 
-- This is a simple program that shows demonstrates the BUG. 
-- 
-- If you run the following program using WIN2000 ver 4.0 binaries or 
-- the WIN98 ver 3.11 binaries. 
-- The ? [$] and the printf both print the same value. 
-- 
-- If you run the same code using WIN98 ver 4.0 binaries then the 
-- ? [$] and the printf DIFFERENT values. 
-- 
-- Of course you have to use include dll.e on the WIN98 ver 3.11 binaries. 
 
-- Start junk.exw ------------------------------------------------------------   
 
include std/dll.e 
 
sequence x 
 
function foo(sequence n) 
n &= define_c_var(open_dll("user32.dll"),n) 
? n[$] 
if n[$] then return sprintf(" %d ",{n[$]}) end if 
end function 
 
x = foo("MessageBeep") 
 
printf(1,x,{}) 
 
if getc(0) then end if 
 
-- End junk.exw ------------------------------------------------------------   
 

3. Re: ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 17, 2008
• 1127 views

 
-- This is a simple program that shows demonstrates the BUG. 
-- 
-- If you run the following program using WIN2000 ver 4.0 binaries or 
-- the WIN98 ver 3.11 binaries. 
-- The ? [$] and the printf both print the same value. 
-- 
-- If you run the same code using WIN98 ver 4.0 binaries then the 
-- ? [$] and the printf DIFFERENT values. 
-- 
-- Of course you have to use include dll.e on the WIN98 ver 3.11 binaries. 
 
-- Start junk.exw ------------------------------------------------------------   
 
include std/dll.e 
 
sequence x 
 
function foo(sequence n) 
n &= define_c_var(open_dll("user32.dll"),n) 
? n[$] 
if n[$] then return sprintf(" %d ",{n[$]}) end if 
end function 
 
x = foo("MessageBeep") 
 
printf(1,x,{}) 
 
if getc(0) then end if 
 
-- End junk.exw ------------------------------------------------------------   
 

This is what I get on WIN98 machine running WIN98 binaries.

3217040639
-2147483648

5. Re: ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 17, 2008
• 1114 views

%x returns
3217040639
80000000

%g returns
3217040639
3.21704e+09

%f returns
3217040639
3217040639.000000

7. Re: ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 17, 2008
• 1149 views

 
-- It has to be there because this code does the same thing. 
 
include std/memory.e 
 
sequence x 
 
x = sprintf(" %d ",{3217040639}) 
printf(1,x,{}) 
 
if getc(0) then end if 
 

9. Re: ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 17, 2008
• 1191 views

// line 3940: (before cstring[flen++] = c;) 
printf("v_elem: %08x, dval: %08x\ngval: %.0f\n", *v_elem, dval, gval ); 

Matt: When I compile with that line I get filesys.obj error. Do I need some include added to be_runtime.c file.

11. Re: ver 4.0 found the BUG in WIN98 code

• Posted by bernie Oct 18, 2008
• 1144 views

// line 3940: (before cstring[flen++] = c;) 
printf("v_elem: %08x, dval: %08x\ngval: %.0f\n", *v_elem, dval, gval ); 

That sysobj error was just a compiler burp. I ran again and it went away.

I put the printf statement in the be_runtime.c but when I ran the
program nothing printed out.

I also tried fprintf to stderr still nothing so thats not where it's happening.

13. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by bernie Oct 18, 2008
• 1127 views

Matt: Look at the code that converts gval for a long integer by
changing it to float.
Could you do the same thing with dval?

15. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by bernie Oct 18, 2008
• 1095 views

   atom a = n[$] 
   print(1, "a %d\n", a ) 
   print(1, "a %d\n", {a} ) 
   ? {n[$]} 
   ? {a} 

Matt:
I actually used rtfatal to sprintf a buffer and I looked at dval
when the program crashed and the the dval was #80000000.
That is -2147483648 which is the the lower limit of long(signed).
It does not return that on win2000 because the long integer may have
different limits. And ver 3.11 may work because the compiled code
never uses memory at those large memory values.

17. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by SDPringle Oct 18, 2008
• 1093 views

I think we are talking about the same compiler here. Watcom C, and once it is compiled it will use the same registers and sizes. I don't think it is a compilation issue. Are you compiling these binaries on a Windows 98 machine? Have you tried the ones I am distributing? I think you should be able to reproduce the bug with either binary. If not, I am wrong.

Shawn

19. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by bernie Oct 18, 2008
• 1102 views

I'am compiling on a WIN2000 machine using MANAGED_MEM option.
I'am running binary on a WIN98 machine.

21. Re: ver 4.0 found the BUG in WIN98 code

• Posted by DerekParnell (admin) Oct 18, 2008
• 1084 views

Bloody hell Bernie! Are trying to make helping you difficult!?

Let's see if I can get a straight and complete answer this time...

You are getting -2147483648 when you use "sprintf".

You are also getting -2147483648 when you use "printf".

In other words, the program below ...

puts(1, sprintf("%d", 3217040639)) 
puts(1, " : from sprintf\n") 
printf(1, "%d : from printf\n", 3217040639) 

Shows the following on your screen...

-2147483648 : from sprintf 
-2147483648 : from printf 

Can you run the following two programs for me ...

-- Program 1 
atom a 
a = 3217040635 
for i = 1 to 10 do 
   puts(1, sprintf("%d: %d", {i, a})) 
   puts(1, "\n") 
   a += 1 
end for 

-- Program 2 
atom a 
a = -2147483645 
for i = 1 to 10 do 
   puts(1, sprintf("%d: %d", {i, a})) 
   puts(1, "\n") 
   a += 1 
end for 

And show us the results you are getting.

By the way, 0x80000000 when stored in a C long integer represents a sequence that has not been allocated any memory in Euphoria. It does NOT represent the lowest Euphoria integer value.

The value 0x800000000 when stored in Euphoria is actually stored as a C double and not a C int.

23. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by ne1uno Oct 18, 2008
• 1104 views
• Last edited Oct 19, 2008

I don't see the problem here on win98SE with many updated programs, IE6, directX 8 and then 9, SP3b2 and many others. any of which could have replaced a dll that is the cause for the bug. using exwc compiled locally w/watcom.

a few unittests could be added and something in sanity.ex to warn someone that erronious results can happen unless they patch their system. patch with what as yet to be determined.

bernie, which version of 98 is it?
rightclick my computer->properties.

anything else installed or is it a plain vanilla win98?

25. Re: ver 4.0 found the BUG in WIN98 code

• Posted by SDPringle Oct 19, 2008
• 1077 views

This strange bug indeed is one that only shows up under certain situations should be squashed. Instead of looking at the printf code I would like to direct your attention to define_c_var code, that is, the underlying C code. It seems to me that somewhere the data is being corrupted inside EUPHORIA. The particular value returned by define_c_var, should vary between windows versions and patch levels. If we just patch the OS and shutup, we will leave a bug that could creep up again later.

Shawn Pringle

27. Re: ver 4.0 found the BUG in WIN98 code FOUND PROBLEM

• Posted by bernie Oct 19, 2008
• 1131 views

I'am running WIN98 Second Edition. version 4.10.2222A
I also just ran the softpedia unofficial upgrade and it made no difference.

29. Re: ver 4.0 found the BUG in WIN98 code

• Posted by mattlewis (admin) Oct 19, 2008
• 1096 views

The first step is to build a debug version of euphoria. Clean the build, and then pass EDEBUG=1 to the wmake command line, in addition to the other stuff. When you installed OpenWatcom, it should have installed its debugger. Look in the start menu, launch it, and run the interpreter, set breakpoints, etc. There should also be a help file for the debugger and all the other stuff that comes with OW.

The debugger is console/text based, but is sort of graphical, like a curses app for windows.

Matt