New engine causes Xorg memory leak?

[jwkuehne]

I have a little Linux standalone test stack created with Rev 3.0 on OS X at

webspace.utexas.edu/kuehne/bug

that does nothing but randomly change the values in four fields, and the background color in the first field.

The standalone works great in OS X and Windows. It also works great in Linux if you make it with legacy 2.6.1

But, the new Linux version causes Xorg to slowly eat all virtual memory. This happens on two RH systems with different kernels and different versions of X. Moving the windows around a bit may be necessary to set it off.

Watch the VIRT and %Mem in 'top'. The percentage will creep up while the program is running, and eventually disaster will ensue.

Would anybody like to try this before I submit a bug report? Try my standalone above , or build your own:

1 create four fields, locked
2 group them, show group name and border
3 write a script flipnumbers for the group that pumps random numbers into the fields, including the symbol for "degrees" in one field and ":" in another.
4 randomly flip the backgroundcolor of one of the fields between 1 of 8 named colors.

Don't put this in a repeat loop. Use send, e.g.

if the label of button "run" is "on" then send flipnumbers to me in 100 milliseconds

It's convenient to have the button "run" that toggles between "on" and "off" so you don't get stuck. Make the "on" state send the first flipnumbers message to the group, and make a standalone.

[malte]

Hi jw,

please report this as a bug. I have seen leakage too, but in a big app. What you have sounds atomic enough to track down the issue, which I have not managed to cook up yet. If it is reported early, chances are higher it gets fixed with the next release.

All the best,

Malte

[jwkuehne]

Ok I will submit it. In the meantime, any testers here, or other anecdotes, would be helpful. Since I already have the standalone, it shouldn't take anyone longer than 10 minutes to see the build-up if it's happening on your system.

Originally I saw this in a large app I'm writing: one that controls a 2.1 meter telescope. At first I thought it was a font caching issue using the degrees-symbol, but removing that doesn't help, although it may take longer for the virtual memory to get eaten, or maybe it just felt that way.

-J

[Bernard]

Hi thanks for posting this. I was beginning to suspect there was something leaking memory on my Linux laptop (I've only been using a Linux desktop for a few weeks now). Rev 3.0 (both stacks and standalones) is completely unstable (in every single possible meaning of that word). I had noticed that there was often 150mb or of swap file, when really I'd done nothing to merit that. I'd wasn't sure what the candidate was (Firefox, Opera, Wine, or Rev), but have been suspecting it's Rev.

Now that I've got some debugging tools going, I hope to prove that it's Rev. It sounds like you have already done that.

[Bernard]

I ran your standalone and can confirm what you say. I saw X virt memory and reserved memory increase by about 2mb every 3 seconds, and never release it.

[heatherlaine]

Please do bug report this via the Quality Center:

http://quality.runrev.com

It sounds like a serious issue which we should be able to track down and fix if reported. The forum is useful for confirming stuff like this with your peers, but to ensure our tech team see it and take action, it must be reported in the Quality Center.

Thanks!

Heather

Customer Services Manager, Runtime Revolution Ltd.

[jwkuehne]

OK, it's entered as a bug report. Sure am glad to have 2.6.1 in the meantime.

-J

[malte]

J,

would you care to post the bug number, as I would want to subscribe to it.

Cheers,

Malte

[jwkuehne]

It's Report #7257 "Rev/Linux can cause Xorg to use up all virtual memory"

-J

[malte]

Thanks a lot.

[FourthWorld]

Thank you for filing the report.

This bit is especially interesting:

Don't put this in a repeat loop. Use send, e.g.

if the label of button "run" is "on" then send flipnumbers to me in 100 milliseconds

That last bit about needing to use "send" is most curious, seeming to imply
that the issue may not have anything to do with the field business, but may
instead be limited to the handling of pending messages.

It would be helpful if someone could try two breaking that up into two
different tests:

- One which does the field manipulation in a repeat loop

- Another which uses "send" to trigger something presumably
innocuous, like "get 1+1"

That would seem helpful to isolating the root cause.

[af]

I've encountered an incredible amount of problems with Revolution 3.0 on OSX.
It is unstable, buggy in many respects which makes it impossible to do any kind of sensible work.

This points to a fundamental problem (memory leak?)

I've created a medium-sized application (50 handlers and functions) and experienced the most strange bugs:

1. Debugging: Sometimes the debugger ignores breakpoints , even after recompiling scripts.

2. The message box doesn't respond to input, or when it is used as output.

3. Clicking the lock to select a certain stack in the message box frequently freezes the whole revolution ide.

4. In the debugger entry points are not stored correctly, even after chosing them more than once.

5. Using saving as... sometimes leads to an infinite loop of saving and reopening stacks.

6. I even lost parts of my code in a script.

7. When I wanted to uninstall revolution in the uninstaller the "next" button
was missing.

and many many more....

All in all this means that Runtime can not be used for any kind of serious development . It is very disappointing that revolution doesn't live up to it's great promises. A pathetic example of software engineering.


I've never encountered such a buggy ide before.

[malte]

All in all this means that Runtime can not be used for any kind of serious development . It is very disappointing that revolution doesn't live up to it's great promises. A pathetic example of software engineering.

Sorry to hear you have had so many problems with the IDE and I agree there some bugs that are annoying I can not let the above comment stand without commenting. There are quite a few examples of serious, mission critical apps made with revolution (I personally helped building a few of them and I know quite a few folks that have successfully built commercially viable apps with it) and personally I am very happy with it as a tool.

Cheers,

Malte

[FourthWorld]

That's quite a diverse list, and many of the items there are things I haven't seen before in using the engine rigorously almost daily for many years.

I don't doubt that you're experiencing them, but am equally confident we can help you whittle that list quite a bit if we learn more about what you're doing.

Since that was the first and only post you've made here so far, we don't know much about what you want to do which might help us help you.

Can you tell us a bit about what you're working on with Rev?

I've encountered an incredible amount of problems with Revolution 3.0 on OSX.
It is unstable, buggy in many respects which makes it impossible to do any kind of sensible work.

This points to a fundamental problem (memory leak?)

I've created a medium-sized application (50 handlers and functions) and experienced the most strange bugs:

1. Debugging: Sometimes the debugger ignores breakpoints , even after recompiling scripts.

2. The message box doesn't respond to input, or when it is used as output.

3. Clicking the lock to select a certain stack in the message box frequently freezes the whole revolution ide.

4. In the debugger entry points are not stored correctly, even after chosing them more than once.

5. Using saving as... sometimes leads to an infinite loop of saving and reopening stacks.

6. I even lost parts of my code in a script.

7. When I wanted to uninstall revolution in the uninstaller the "next" button
was missing.

and many many more....

All in all this means that Runtime can not be used for any kind of serious development . It is very disappointing that revolution doesn't live up to it's great promises. A pathetic example of software engineering.


I've never encountered such a buggy ide before.

[af]

>>Can you tell us a bit about what you're working on with Rev?<<

I was taking revolution for a test drive in order to decide whether to use Adobe Director or Revolution to create multimedia e-Learning applications. I first tried Revolution because it supports SQLite.

I wrote a script which automatically collects test handlers (i.e. database tests) from a stack and executes them and reports which tests failed/passed, similar to jUnit/Smalltalk, in order to do test first development and make future refactoring easier. There is nothing like good tests for more complex projects.

I don't think the problems I've encountered are connected to what I did. I just collected test functions from a script, put them into an array and executed them using do, collected the test results and put them into a table field (BTW support for tables could be better).

I succeeded (until I was fed up with the unstable IDE) and I really like the revolution scripting language because you can easily achieve many things which take much more time using other languages. The language/system design has some minor drawbacks, but I could live with them.

The problem is not the language but the IDE. It is too unstable and unreliable. I suspect that those people who developed mission critical
applications in RunRev didn't use the native scripting environment.

I really have to apologize for my harsh criticism, but to my mind the IDE can not be used the way things are. The frequent problems/squirks/bugs use up too much time.

I'll try Adobe Director next, but I would definitively be willing to give Revolution another chance, provided that the IDE works flawlessly.

As your marketing people said, "our customers live in the IDE", my code almost died in it. The Revolution 3.0 was probably released prematurely. I've used many different IDEs and languages so far, but I never had such a disapointing experience.

Kind regards,

Andreas.