Home » forums » The breve Simulation Environment » Bug Reports

New breve 2.4 beta feedback thread [04/23/06]

This is the official feedback thread for the new betas posted 04/23:

http://www.spiderland.org/breve_2.4_betas/

- jon

‹ breve 2.4 bug fix suggestions Tools menu and keyboard control ›
»
Submitted by jk on Sun, 2006-04-23 22:32.

load-as-xml

Submitted by ckowall on Fri, 2006-04-28 02:15.

+ to load-drivers:
i(int).
obj(object).
s(string).
obj = new Configuration.
for i = 0, i < NUM_EXPOSURE, i++:{
#foreach obj in testset:{
s = "TestSet$i.xml".
obj load-from-xml file s.
#testset{ i } = obj.
push obj onto testset.
print "loading $i $obj $s".
}
This gets me all of the same object. It should give me a list of NUM_EXPOSURE configurations.
breveIDE for windows

»

more

Submitted by ckowall on Fri, 2006-04-28 03:06.

save-with-dialog hangs in windowsIDE.
it appears as windows not IDE doesn't work at all.

»

HUGE bug - sorting is reversed in the last version(?)

Submitted by PowerMacX on Sat, 2006-04-29 18:19.

Hi, after discovering some very strange results in my bug evolution simulation when running on the last version of breve 2.4 beta, I finally found out what I think is a rather serious bug, in the sense that it can potentially affect a lot of simulations. The sort method gives the results in the opposite order than the previous version!

I made the following test case:

@use Control.

Controller ListTest.

Control : ListTest
{
    + to init:
        myList (list).
        thing (object).

        myList = 5 new Things.
        myList{0} set-value to 0.
        myList{1} set-value to 2.
        myList{2} set-value to 1.
        myList{3} set-value to 5.
        myList{4} set-value to 3.
        
        print "Before sorting:".

        foreach thing in myList:
            print (thing get-value).

        print "After sorting:".

        sort myList with compare-values.
        foreach thing in myList:
            print (thing get-value).

        self end-simulation.

    + to compare-values of a (object) with b (object):
        return ((a get-value) - (b get-value)).
}

Object : Thing (aka Things)
{
    + variables:
        value (int).
        
    + to set-value to val (int):
        value = val.
        
    + to get-value:
        return value.
}

Result from the 2006/03/27 Mac OS X build of the 2.4 beta:

Before sorting:
0
2
1
5
3
After sorting:
0
1
2
3
5

Result from the 2006/04/23 Mac OS X build of the 2.4 beta:

Before sorting:
0
2
1
5
3
After sorting:
5
3
2
1
0

May I suggest you add this test (and others like this) to a regression test suite for breve builds? It seems that every new beta fixes a lot of bugs but unfortunately also introduces a few new ones. :(
A comprehensive regression suite/unit testing could help avoid that.

»

Re: HUGE bug - sorting is reversed in the last version(?)

Submitted by jk on Sat, 2006-04-29 18:51.

PowerMacX wrote:Hi, after discovering some very strange results in my bug evolution simulation when running on the last version of breve 2.4 beta, I finally found out what I think is a rather serious bug, in the sense that it can potentially affect a lot of simulations. The sort method gives the results in the opposite order than the previous version!

Ouch, sorry about this, how embarrassing. This was a bug in an earlier version of the betas, which I fixed *twice* (changing the order, and then changing the order back again) by mistake. I must be schizophrenic!

Observe the subversion log for the sorting file:

------------------------------------------------------------------------
r647 | jonklein | 2006-04-21 20:07:05 -0400 (Fri, 21 Apr 2006) | 5 lines

- fixed list sorting 


------------------------------------------------------------------------
r646 | jonklein | 2006-04-18 22:38:45 -0400 (Tue, 18 Apr 2006) | 2 lines

- fixed sort ordering

I will be making a new set of builds tomorrow which will include the (third and final) fix!

- jon

»

New breve 2.4 beta feedback thread [04/23/06]

Submitted by PowerMacX on Sat, 2006-04-29 22:15.

Great! Tnx.

»

2.4 RC1 Memory Leak / Crash

Submitted by PowerMacX on Sat, 2006-05-13 18:34.

I made a small test case to see whether breve was still leaking memory. The good news is that it seems to be fixed on the 2.4 RC1, the bad news is that it occasionally crashes now. :(
This is the test case I used (basically the same I posted elsewhere, but I added a super iterate call to the controller):

@use Control.

Controller MemoryLeakTest.

Control : MemoryLeakTest
{
    + variables:
        thing (object).

    + to init:
        (self execute command "open /Applications/Utilities/Activity\ Monitor.app").
        self disable-freed-instance-protection.
        thing = new Thing.
        thing set-value to 123.
        
    + to iterate:
        i (int).
        for i=0,i<100,i++:
        {
            free thing.
            thing = new Thing.
            thing set-value to 123.
        }
        #print "Objects:",|all Objects|. # Uncomment this line to verify that the Object count remains the same
        super iterate.
}

Object : Thing (aka Things)
{
    + variables:
        value (int).
        #filler1, filler2, filler3 (500 ints). # Uncomment this to verify that the size of the object has no impact
        
    + to set-value to val (int):
        value = val.
        #filler1[499] = val. filler2[499] = val. filler3[499] = val. # Uncomment this to verify that the size of the object has no impact
        
    + to get-value:
        return value.
}

And this is the crash report:

Date/Time:      2006-05-13 19:58:35.227 -0300
OS Version:     10.4.6 (Build 8I127)
Report Version: 4

Command: breve
Path:    /Applications/breve.app/Contents/MacOS/breve
Parent:  WindowServer [163]

Version: 2.4RC1 (2.4RC1)

PID:    289
Thread: 4

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xa1b1c1e7

...

Thread 4 Crashed:
0   org.spiderland.breve      	0x00035d30 stInstanceUnretain(stInstance*) + 8 (crt.c:355)
1   org.spiderland.breve      	0x0001a1cc stGCUnretainAndCollectPointer(void*, int) + 124 (crt.c:355)
2   org.spiderland.breve      	0x00492868 stEvalFree(stFreeExp*, stRunInstance*, brEval*) + 520 ((null):-1)
3   org.spiderland.breve      	0x0048f068 stEvalCodeArray(stCodeArrayExp*, stRunInstance*, brEval*) + 136 ((null):-1)
4   org.spiderland.breve      	0x0048f83c stEvalFor(stForExp*, stRunInstance*, brEval*) + 300 ((null):-1)
5   org.spiderland.breve      	0x0001e3a8 stCallMethod(stRunInstance*, stRunInstance*, stMethod*, brEval**, int, brEval*) + 512 (crt.c:355)
6   org.spiderland.breve      	0x00028ef4 stCallMethodBreveCallback(void*, void*, brEval**, brEval*) + 72 (crt.c:355)
7   org.spiderland.breve      	0x000279ac brEngineIterate + 524 (crt.c:355)
8   org.spiderland.breve      	0x00013bf8 -[slBreveEngine runWorld:] + 404 (crt.c:355)
9   com.apple.Foundation      	0x92976194 forkThreadForFunction + 108
10  libSystem.B.dylib         	0x9002ba68 _pthread_body + 96

Thread 4 crashed with PPC Thread State 64:
  srr0: 0x0000000000035d30 srr1: 0x000000000200d030                        vrsave: 0x0000000000000000
    cr: 0x84000422          xer: 0x0000000000000004   lr: 0x000000000001a1cc  ctr: 0x0000000000000002
    r0: 0x0000000000000001   r1: 0x00000000f0203850   r2: 0x00000000019c8b60   r3: 0x00000000a1b1c1d3
    r4: 0x0000000000000005   r5: 0x0000000005528d80   r6: 0x00000000ffffffff   r7: 0x00000000019ec1f4
    r8: 0x0000000000000001   r9: 0x00000000a0001fac  r10: 0x0000000000000000  r11: 0x0000000000000005
   r12: 0x000000009000660c  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x0000000000000000
   r16: 0x0000000000000000  r17: 0x0000000000000000  r18: 0x0000000000000000  r19: 0x00000000f0203c08
   r20: 0x0000000000000000  r21: 0x00000000f0203c60  r22: 0x0000000000000000  r23: 0x00000000f0203c08
   r24: 0x00000000020c3904  r25: 0x00000000053ea000  r26: 0x00000000003e4588  r27: 0x0000000000000000
   r28: 0x00000000f0203c60  r29: 0x00000000f0203c08  r30: 0x00000000019c8b60  r31: 0x0000000000000005

Binary Images Description:
    0x1000 -   0x4d2fff org.spiderland.breve 2.4RC1	/Applications/breve.app/Contents/MacOS/breve
...

Please note that it doesn't happen frequently in this simple test case I made, but in my real simulation I get crashes every time after a few minutes when running on 2.4 RC1. I still haven't been able to find a consistent "crash point" in my code though (it being 3000+ lines long doesn't help :( ). Turning on freed-instance-protection didn't seem to make any difference.

Here is a crash report from my full sim:

Date/Time:      2006-05-13 20:30:18.267 -0300
OS Version:     10.4.6 (Build 8I127)
Report Version: 4

Command: breve
Path:    /Applications/breve.app/Contents/MacOS/breve
Parent:  WindowServer [163]

Version: 2.4RC1 (2.4RC1)

PID:    329
Thread: 4

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x078003ff

...

Thread 4 Crashed:
0   org.spiderland.breve      	0x00035d30 stInstanceUnretain(stInstance*) + 8 (crt.c:355)
1   org.spiderland.breve      	0x0001a1cc stGCUnretainAndCollectPointer(void*, int) + 124 (crt.c:355)
2   org.spiderland.breve      	0x0003c580 brEvalListHead::~brEvalListHead [in-charge deleting]() + 128 (crt.c:355)
3   org.spiderland.breve      	0x000361e8 stInstanceFreeInternals(stInstance*) + 120 (crt.c:355)
4   org.spiderland.breve      	0x00039240 stInstanceFreeNoInstanceLists(stInstance*) + 92 (crt.c:355)
5   org.spiderland.breve      	0x000393b4 stInstanceFree(stInstance*) + 24 (crt.c:355)
6   org.spiderland.breve      	0x0002e2f0 brInstanceFree + 60 (crt.c:355)
7   org.spiderland.breve      	0x0002e4e8 brInstanceRelease + 104 (crt.c:355)
8   org.spiderland.breve      	0x004927b4 stEvalFree(stFreeExp*, stRunInstance*, brEval*) + 340 ((null):-1)
9   org.spiderland.breve      	0x0001e3a8 stCallMethod(stRunInstance*, stRunInstance*, stMethod*, brEval**, int, brEval*) + 512 (crt.c:355)
10  org.spiderland.breve      	0x0001e8d4 stCallMethodByName(stRunInstance*, char*, brEval*) + 140 (crt.c:355)
11  org.spiderland.breve      	0x00039228 stInstanceFreeNoInstanceLists(stInstance*) + 68 (crt.c:355)
12  org.spiderland.breve      	0x000393b4 stInstanceFree(stInstance*) + 24 (crt.c:355)
13  org.spiderland.breve      	0x0002e2f0 brInstanceFree + 60 (crt.c:355)
14  org.spiderland.breve      	0x0002e4e8 brInstanceRelease + 104 (crt.c:355)
15  org.spiderland.breve      	0x00492730 stEvalFree(stFreeExp*, stRunInstance*, brEval*) + 208 ((null):-1)
16  org.spiderland.breve      	0x0048f068 stEvalCodeArray(stCodeArrayExp*, stRunInstance*, brEval*) + 136 ((null):-1)
17  org.spiderland.breve      	0x0048e11c stEvalIf(stIfExp*, stRunInstance*, brEval*) + 236 ((null):-1)
18  org.spiderland.breve      	0x0048c460 stRealEvalMethodCall(stMethodExp*, stRunInstance*, stRunInstance*, brEval*) + 896 ((null):-1)
19  org.spiderland.breve      	0x0048d364 stEvalMethodCall(stMethodExp*, stRunInstance*, brEval*) + 212 ((null):-1)
20  org.spiderland.breve      	0x0048e11c stEvalIf(stIfExp*, stRunInstance*, brEval*) + 236 ((null):-1)
21  org.spiderland.breve      	0x0048c460 stRealEvalMethodCall(stMethodExp*, stRunInstance*, stRunInstance*, brEval*) + 896 ((null):-1)
22  org.spiderland.breve      	0x0048d364 stEvalMethodCall(stMethodExp*, stRunInstance*, brEval*) + 212 ((null):-1)
23  org.spiderland.breve      	0x0048c460 stRealEvalMethodCall(stMethodExp*, stRunInstance*, stRunInstance*, brEval*) + 896 ((null):-1)
24  org.spiderland.breve      	0x0048d364 stEvalMethodCall(stMethodExp*, stRunInstance*, brEval*) + 212 ((null):-1)
25  org.spiderland.breve      	0x0048f068 stEvalCodeArray(stCodeArrayExp*, stRunInstance*, brEval*) + 136 ((null):-1)
26  org.spiderland.breve      	0x0048e11c stEvalIf(stIfExp*, stRunInstance*, brEval*) + 236 ((null):-1)
27  org.spiderland.breve      	0x0048f068 stEvalCodeArray(stCodeArrayExp*, stRunInstance*, brEval*) + 136 ((null):-1)
28  org.spiderland.breve      	0x0048e11c stEvalIf(stIfExp*, stRunInstance*, brEval*) + 236 ((null):-1)
29  org.spiderland.breve      	0x0001e3a8 stCallMethod(stRunInstance*, stRunInstance*, stMethod*, brEval**, int, brEval*) + 512 (crt.c:355)
30  org.spiderland.breve      	0x00028ef4 stCallMethodBreveCallback(void*, void*, brEval**, brEval*) + 72 (crt.c:355)
31  org.spiderland.breve      	0x000279ac brEngineIterate + 524 (crt.c:355)
32  org.spiderland.breve      	0x00013bf8 -[slBreveEngine runWorld:] + 404 (crt.c:355)
33  com.apple.Foundation      	0x92976194 forkThreadForFunction + 108
34  libSystem.B.dylib         	0x9002ba68 _pthread_body + 96

Thread 4 crashed with PPC Thread State 64:
  srr0: 0x0000000000035d30 srr1: 0x000000000000f030                        vrsave: 0x0000000000000000
    cr: 0x44000222          xer: 0x0000000020000007   lr: 0x000000000001a1cc  ctr: 0x000000000003c500
    r0: 0x0000000000000001   r1: 0x00000000f0202ba0   r2: 0x00000000004fbd78   r3: 0x00000000078003eb
    r4: 0x0000000000000005   r5: 0x0000000000000000   r6: 0x00000000ffffffff   r7: 0x0000000000000000
    r8: 0x0000000000000000   r9: 0x0000000000019f70  r10: 0x0000000000000000  r11: 0x0000000006184a80
   r12: 0x000000000003c500  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x00000000f0203c60
   r16: 0x00000000f0203360  r17: 0x00000000f0203698  r18: 0x0000000000000000  r19: 0x0000000000000000
   r20: 0x0000000000000000  r21: 0x00000000f0203010  r22: 0x00000000054ca05c  r23: 0x00000000f0202fa8
   r24: 0x0000000005590ce0  r25: 0x00000000061d71e0  r26: 0x000000000551e2b0  r27: 0x0000000006103908
   r28: 0x0000000006103900  r29: 0x000000000610390c  r30: 0x00000000057a07b0  r31: 0x0000000000000005

Binary Images Description:
    0x1000 -   0x4d2fff org.spiderland.breve 2.4RC1	/Applications/breve.app/Contents/MacOS/breve
...
»

Re: 2.4 RC1 Memory Leak / Crash

Submitted by jk on Mon, 2006-05-15 08:06.

PowerMacX wrote:I made a small test case to see whether breve was still leaking memory. The good news is that it seems to be fixed on the 2.4 RC1, the bad news is that it occasionally crashes now. :(

Hi there,
can you do me a favor and re-download RC1 and test it again? I had uploaded a version of RC1, but then saw the same problem and so I reverted back to the older behavior. So it's possible that you grabbed the older RC1 build.

Please try it with the latest build and let me know if you still encounter the problem. The test code you gave appears to be stable even over a large number of runs.

- jon

»

New breve 2.4 beta feedback thread [04/23/06]

Submitted by PowerMacX on Sat, 2006-05-20 04:42.

Sorry for not answering sooner, I've been real busy this week.

So, I downloaded the RC1 again, and it does seem to be a different version from the one I downloaded earlier (dated 2006-05-04 vs. 2006-05-09).
The crashes are gone, I ran my simulation for several hours without problems, but sadly it seems that the memory leaks are back. :(

I'll try the release version today.

»

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.