1. Genuine Bug Report
- Posted by Mario Steele <eumario at trilake.net> Feb 24, 2005
- 518 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
2. Re: Genuine Bug Report
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 24, 2005
- 511 views
- Last edited Feb 25, 2005
Mario Steele wrote: > 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. > ... > ... 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. 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 http://www.RapidEuphoria.com
3. Re: Genuine Bug Report
- Posted by Mario Steele <eumario at trilake.net> Feb 25, 2005
- 488 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
4. Re: Genuine Bug Report
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 25, 2005
- 497 views
Mario Steele wrote: > 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. That's OK. I thought about the information you provided yesterday, and I went into the interpreter code and found a subtle, but easy to fix, bug that completely explains everything you reported. In fact, I created my own example that shows the same sort of problem you reported. The bug is in all versions of Euphoria since call_proc() and call_func() were added. It only affects the error traceback that you might get if you erroneously supply a sequence as the routine id. Even in that case, you could often get a correct, or almost correct traceback. Anyway, it's fixed now for the official release (a week or so?). Thanks for reporting it. Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com