>>> (reason enough to not like C++)

Leaking handles is not a language specific problem. You can leak handles in any language if you obtain them, and don't free them. It is a design issue, or sloppy coding.

Eh... I'd beg to differ, at least in part. "If you obtain them", then yes - but if the language itself takes care of such details, and properly disposes of the ones _it_ gets, removing such "don't forget to do this" load from the programmer, then it's not an issue. C is very "low level" - the programmer is responsible for everything. This is great if what you are after is very fast, "tight" code, but if you are after _bug_free_ code, then there are much better choices than any flavor of C. Even within "3rd generation" languages such as C, Pascal, BASIC, etc., NONE of which I would classify as "bug resistant", C is pretty well known as being the easiest to mess up in. The "++" (OOP) part is just a joke. It's neither true OOP (see Smalltalk) nor a real improvement on anything except programmer productivity.

Bugs can be created in any language, but there _are_ languages that were designed to minimize the possiblity. The entire "4th generation language" effort of a couple of decades back comes to mind. Unfortunately, none of those ever gained enough commercial success to supplant the 3GLs, although part of what was learned (but not the best part, imho) has since shown up in things like SQL.

---

Back for a moment to 'client errors'. My old, slow host 76452 that was returning WUs with errors consistently now seems to have gotten over its problems. I did reboot it several times over the weekend and in the process found that it was booting up and automatically logging in (to WinXP) as admin. I think it was trying to run the same WU in two different processes as two different users. I think I've fixed that, and I see at least some successes coming from that machine now.

However, of the two systems that are up and online 24x7 (76452 and 78132), I seem to be getting spurious 'client errors' in the results. If this is something I can fix I'd like to, but I'm not finding any help on the bakerlab site to help me determine the root cause.

Also, I noticed that the faster machine somehow finished 28 WUs in less than 24 hours yesterday (this seems unlikely) and then returned a string of errors because BOINC would not assign it any more work, and yet it continued to solicit more work, and each of the dozens of attempts was recorded as as an error. No biggie, but it seems the client ought to be smart enough to back off when the server says to.

Now to OO languages and memory leaks. I lead a Denver Java User Group Object Orient Architecture Special Interest Group (say that fast five times!). We had a Sun master instructor speak on garbage collection in Java recently. I was a bit surprised that Java can have memory leaks until I realized what he was talking about was simply opening a file handle or connection or whatever and not closing it in a JVM that doesn't terminate for long periods. This is poor form even in a 'safe' language, and the programmer can certainly be blamed. However, when the JVM terminates, my understanding is that any open resources are then released. I'm not sure this is true with C. I think there are situations where even after the process terminates that owns the resource, the OS cannot reclaim it. I don't know C well - is this true?

The moral, I guess, is that memory leaks can and do occur even in 'safe' languages, but in programs that are not services (processes that run indefinitely), the 'safe' languages are indeed safe. Make sense?

G

---

We had a Sun master instructor speak on garbage collection in Java recently. I was a bit surprised that Java can have memory leaks until I realized what he was talking about was (snip)

I don't know C well - is this true?

I knew one of the people who wrote an early Java implementation. At _that_ time, Java's garbage collection was pathetic, almost an "inside joke", and one of the reasons Sun hired so many of the folks from ParcPlace. I would hope that in the years since, it's improved...

C has the "power" to do as you describe, but I would think it unlikely if the application in question were running in the "user" space. That's more OS-dependent than anything. Even if the app doesn't clean up, the OS should.

However, of the two systems that are up and online 24x7 (76452 and 78132), I seem to be getting spurious 'client errors' in the results.

I'm looking at those two, will report back if I find anything helpful.

---

However, of the two systems that are up and online 24x7 (76452 and 78132), I seem to be getting spurious 'client errors' in the results.

I'm looking at those two, will report back if I find anything helpful.

76452 is running V5.2.8, and had a lot of errors before suddenly starting to work Dec 4. 78132 is running V5.2.7, worked fine for a while, then had a TON of errors on Dec 4, and began working again on Dec 5. Very strange.

The errors are mostly (all?) the "incorrect function (0x1) - exit code 1 (0x1)" thing that I have no clue about. There were a handful of errors back in November that appear to have been the "leave in memory" issue, but it looks like that is solved. At first I thought the latest errors started when Rosetta 4.80 replaced 4.79, but you had "good" results from 4.80 on 78132 both before and after the errors.

If you know of anything that "changed" on the 4th, that would cause one to stop having errors and the other to start... Maybe the screensaver? I'm grasping at straws here, but if the screensaver were causing these "0x1" errors on your particular video card, you could verify this by using something else for a bit, then switching back, and seeing if the errors return. I suppose another possibility would be overheating, but the pattern doesn't look right for that. Is there anything "CPU intensive" that would have been running one day on one and the next day on the other? (Someone reported that BOINC would give errors if they didn't exit before running some heavy-duty game...)

There shouldn't be any need to update to 5.2.13 (or .14, if it's passed testing) as none of the fixes between .7 and now _should_ have anything to do with this. Still, if this continues to happen, that's one thing to try.

---

>>> but if the language itself takes care of such details,

A language, to be portable across platforms, would not use "handles" since the OS under it might not. The compiler might, but then if the compiler is obtaining and not releasing handles/resources we come back to the point I made, it is a design issue or sloppy coding. In 25+ years of software development, I've seen enough of these things.

Garbage collection won't always work. I've never seen a language/compiler/OS combo that made it absolutely impossible to leak.

>>> I don't know C well - is this true?

Once again, the language as such can't do that, but I can envisage situations where on certain OS's that could happen, but that again, would not be the fault of the language per se, if it was possible in C, then I would think it would be equally possible in Pascal, Fortran, Java whatever.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Things seem to be running well enough now that I don't think there's any use refining. However, I still suspect Konfabulator might be conflicting with Rosetta in some way because I've seen it (Konfabulator ) crash a few times recently for no apparent reason and that's never happened before. It's a desktop widget thingie that might be getting into Rosetta's face for video resources.

Bill, thanks for all your help.

You're over my head on the leak thing. Yesterday I noticed something funny, though. I had a web app running in Tomcat that creates JPEG files, and I commented out the ObjectOutputStream.close() statement to learn more about an I/O error I was getting. I found that even after shutting down Tomcat I could not delete the directory the files were created in. Windows Explorer hung for a while and finally refused to delete them when I attempted to, complaining that they were locked. I decided to reboot and while the system was shutting down I saw Windows Explorer (which had hung again after I asked it to delete them) suddenly delete the directory, then exit. Something was holding them open, but the JVM process in which they were created was gone.

For my purposes, writing clean I/O is sufficient. Anything that happens when I don't is in the PFM category (pure magic).

---

Seems this is a place to ask this.

I'm a new Rosetta user and in the above thread I heard mention that Rosetta needs me to set preferences to 'always store in memory' in order for it to run properly? Is this so?

Thank you.

---

Founder of BOINC GROUP - Objectivists - Philosophically minded rational data crunchers.

Seems this is a place to ask this.

I'm a new Rosetta user and in the above thread I heard mention that Rosetta needs me to set preferences to 'always store in memory' in order for it to run properly? Is this so?

Thank you.

Its better for all projects not getting an error ;)

---