OpenEuphoria

1. Genuine Bug Report

• Posted by Mario Steele <eumario at trilake.net> Feb 24, 2005
• 520 views

Okay, I know this bug report is a Genuine report, cause this is in no way my
fault, considering I can't control how Euphoria generates the markers for where
a program crashed, and is no feature, considering it is mis-leading in the way
that it reports the error.

I'm currently working on my Object Oriented Programming Library, soon to be
released, when I ran into this bug, that involves the way the internal crash
messages are generated, and markers for where the program actually crashed.

I accedently wrote my method_proc() function, to be passing a sequence to
call_func()/call_proc(), and it was calling out the right error, however, the
trace-back of this, was completely off track.

Ex.err File (Only needed info):
C:\euproj\poop\poop.e:78 in function sub_find() 
call_proc/call_func: an integer was expected, not a sequence 
    what = <no value>
    in = <no value>
    lvl = <no value>
    x = <no value>

... called from C:\euproj\poop\test2.ex:17 in function MyWindow_create()  

... called from C:\euproj\poop\poop.e:327 in function new()  
---<SNIP>---
Traced lines leading up to the failure:

C:\euinc\w32dll.ew:197		        if vw32Libraries[lFuncDef[1]][1][1] = 0 then
C:\euinc\w32dll.ew:201		        lFuncDef[1] = vw32Libraries[lFuncDef[1]][1][2]
C:\euinc\w32dll.ew:204		    lFuncDef = linkFunc(lFuncDef[1], -- library
C:\euinc\w32dll.ew:209		    vw32Routines[funcid] = lFuncDef
C:\euinc\w32dll.ew:212	        lRC = c_func(lFuncDef, parms)
C:\euinc\w32dll.ew:179	    memset = 0
C:\euinc\w32dll.ew:180	    for i = 1 to length(parms) do
C:\euinc\w32dll.ew:181	        if sequence(parms[i]) then
C:\euinc\w32dll.ew:187	    end for
C:\euinc\w32dll.ew:181	        if sequence(parms[i]) then
C:\euinc\w32dll.ew:187	    end for
C:\euinc\w32dll.ew:181	        if sequence(parms[i]) then
C:\euinc\w32dll.ew:187	    end for
C:\euinc\w32dll.ew:181	        if sequence(parms[i]) then
C:\euinc\w32dll.ew:187	    end for
C:\euinc\w32dll.ew:189	    if funcid > kMagicRtnID then
C:\euinc\w32dll.ew:190	    funcid -= kMagicRtnID
C:\euinc\w32dll.ew:191	    if funcid <= length(vw32Routines) then
C:\euinc\w32dll.ew:192	        lFuncDef = vw32Routines[funcid]
C:\euinc\w32dll.ew:194	        if sequence(lFuncDef) then
C:\euinc\w32dll.ew:212	        lRC = c_func(lFuncDef, parms)
C:\euinc\w32dll.ew:224	    if memset != 0 then
C:\euinc\w32dll.ew:228	    return lRC
C:\euinc\w32dll.ew:224	    if memset != 0 then
C:\euinc\w32dll.ew:228	    return lRC
---<END_OF_EX.ERR>---

Now, reviewing my library, sub_find() is declared like this:

75: function sub_find(object what, sequence in, integer lvl)
76: 	for x = 1 to length(in) do
77: 		if equal(what,in[x][lvl]) then
78: 			return x
79: 		end if
80: 	end for
81: 	return 0
82: end function

The routine in which the actual error occured is declared like this:

423: global procedure method_proc(atom ix, sequence name, sequence args)
424: 	atom class_ix, m_ix, restore
425: 	check_this()
426: 	if ValidObject(ix) then
427: 		class_ix = find(object_class[ix],class_name)
428: 		m_ix = sub_find(name,class_methods[class_ix],1)
429: 		if m_ix then
430: 			restore = this
431: 			this = ix
432: 			lib_this = this
433: 			call_proc(class_methods[class_ix][m_ix][2],args)
434: 			this = restore
435: 			lib_this = this
436: 		else
437: 			error("method_proc",{ix,name,args},"Method has not been declared at this
point.")
438: 		end if
439: 	else
440: 		error("method_proc",{ix,name,args},"Invalid Class object given.")
441: 	end if
442: end procedure

Line 433 was where the error actually occured, and the line read like this:

call_proc(class_methods[class_ix][m_ix],args)

However, I would never had found it, just by looking at the ex.err file.
This will proabbly be reproducable, by changing line 433 back to the one
listed above, as soon as I publish the official source code.  I'm currently
in works, of finishing up the library, and releasing it to the Public Domain,
but, if you want to see exactly how this error occured Rob, I will be more
then happy to restore the original code to where this error occured, and
test files I used, pass it along to you to see what is going on.

L8ers,
Mario Steele

3. Re: Genuine Bug Report

• Posted by Mario Steele <eumario at trilake.net> Feb 25, 2005
• 489 views

Robert Craig wrote:
<snip>
> Yes, can you please send me source code that shows the problem? 
> I can't solve it just from what you've given me so far.
> 
> Thanks,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> 

Thanks to the modifications I made yesterday to the library to fix other bugs,
and then forgetting where this bug originally occured, I am now unable to
re-produce the error.  In either case, I am going to be re-designing the
library in any case, in order to effectivly eliminate the original problem
I had, with sequences dis-appearing on me.  Cause now, since I'm doing this:

for x = 1 to length(object_vtbl[ix]) do
    if sequence(object_vtbl[ix][x][2]) then
        new_ix = new(object_vtbl[ix],args)
        object_vtbl[ix][3] = new_ix
    end if
end for

The sequence now changes from having
{First Instance, Second Instance, Third Instance}
to Having:
{First Instance, Third Instance}
When it returns from the recursive new() call, and the program errors
out completely.  So, for now, I'll re-design the library to have sequences
as mear Memory Pointers, to C Structs to store valuable data, and simply
append the new structure to the correct position in the sequence.

*le-sigh*
Mario Steele