http://setiathome.berkeley.edu/result.php?resultid=3379306664

Am I missing it, or does the stderr not say what the problem is?

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

http://setiathome.berkeley.edu/result.php?resultid=3379306664

Am I missing it, or does the stderr not say what the problem is?

Stderr on your WU doesn't tell much of anything, but it isn't always a useful diagnostic tool. The actual result file might tell how different from the others your result was, but we seldom get to see those.

If it's only the one result, it could have been a number of one-time errors or glitches - power fluctuation, cosmic ray hit a memory chip, you know. If you start getting a lot of them, might be time for a reboot or cleaning. Just one shouldn't be a problem.

---

Donald
Infernal Optimist / Submariner, retired

http://setiathome.berkeley.edu/result.php?resultid=3379306664

Am I missing it, or does the stderr not say what the problem is?

It was a Truncated Stderr on an Overflow with less than 30 Spikes.

There is a Whole Thread About That Problem;
Strange Invalid MB Overflow tasks with truncated Stderr outputs...

As TBar noted, you got hit with the Strange Invalid MB Overflow tasks with truncated Stderr outputs... problem. It's a 2-part issue, the first being the truncated Stderr output. Those truncations seem to happen on any Windows platform and can occur on NVIDIA or ATI GPUs, as well as on the CPU. These have apparently been happening for all of recorded history. Jason seems to have a workaround for Cuda but, for now, it's only a workaround.

The second part of the problem is a validator issue which got introduced by Eric last July when he was trying to prevent nefarious users from running v7 tasks through v6 apps. What appears to be a fairly simple fix to that side of the problem, which would make the truncated Stderr issue moot for now, was identified a couple weeks ago and Joe Segur wrote:

I guess we've pretty well covered the various conditions which affect the issue, so I'll send Eric an email with the suggestion this week.

So far there doesn't seem to be a response.

In the meantime, for whatever reason, I seem to be seeing the problem happening more frequently lately. Where it used to be once every week or two, now I'm catching a couple every week. My latest two, on different machines, are in tasks 3381930455 and 3379123672.

Oh. I've seen that thread but not read it. AFAIK, this is the first time it's happened to me. Thanks for telling me what it is.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

...
What appears to be a fairly simple fix to that side of the problem, which would make the truncated Stderr issue moot for now, was identified a couple weeks ago and Joe Segur wrote:

I guess we've pretty well covered the various conditions which affect the issue, so I'll send Eric an email with the suggestion this week.

So far there doesn't seem to be a response.
...

For the record, Eric replied to my email January 30:

Thanks. I'll figure out how to best implement.

I take that as a favorable response. Eric is of course too sensible to predict when he'll have time to consider and implement.

                                                                   Joe

I take that as a favorable response. Eric is of course too sensible to predict when he'll have time to consider and implement.

                                                                   Joe

Perhaps when he gets tired of playing around with Android, or when Hades freezes over, whichever comes first. ;^)

I've always believed, though, that in the absence of separate development and support staffs, fixing problems in existing production applications should always take precedence over future development, particularly when the timeline for that development is so vague.

I take that as a favorable response. Eric is of course too sensible to predict when he'll have time to consider and implement.

                                                                   Joe

Perhaps when he gets tired of playing around with Android, or when Hades freezes over, whichever comes first. ;^)

I've always believed, though, that in the absence of separate development and support staffs, fixing problems in existing production applications should always take precedence over future development, particularly when the timeline for that development is so vague.

That would be a reasonable assumption if Eric (and Matt and Jeff) had no other responsibilities beyond Seti@Home. That is not the case. There are NO full-time, exclusively Seti@Home staffers. ALL the Seti@Home staffers also work on other projects at the Space Science Lab. Sometimes other projects take priority, and sometimes the "fix" is more difficult to accomplish than it first appeared, which is why Eric prefers not to commit to deadlines.

---

Donald
Infernal Optimist / Submariner, retired

That would be a reasonable assumption if Eric (and Matt and Jeff) had no other responsibilities beyond Seti@Home. That is not the case. There are NO full-time, exclusively Seti@Home staffers. ALL the Seti@Home staffers also work on other projects at the Space Science Lab. Sometimes other projects take priority

I actually just meant to refer to the balance between development and support priorities within Seti@Home, not to pit S@H against their other projects. Admittedly, we're on the outside looking in (through some rather opaque glass, I'd have to say), but it seems to me that available S@H resources are currently devoted primarily to Android development, with little interest in addressing production issues.

Although I'm sure it's much more challenging (and fun, from a technical perspective) to be playing around with Android, I don't see where there's a pressing deadline there (or even a vague timeline). On the other hand, I've seen numerous production-related issues raised on these Message Boards over the last several months (including identifiable S@H bugs, S@H/BOINC interactions, squandering of resources, database cleanup, etc., etc.), which seem to have drawn little, if any, attention from the project admins. I think it's time for them to refocus their S@H energies for a time.

sometimes the "fix" is more difficult to accomplish than it first appeared, which is why Eric prefers not to commit to deadlines.

Of course, but in this particular instance I'd have to say that most, if not all, of the "grunt" work of analyzing the problem, zeroing in on the source, and identifying a simple and workable fix, was accomplished without requiring S@H staff involvement. Since the fix isn't something that needs to be rolled out in a science app, but is rather a validator change on the server side, the degree of difficulty (for a non-Olympics event, anyway) shouldn't be that great, if he'd take the time to focus on production issues for a while.

But who is to say that Android is being developed on Seti@Home time. For all we know it could be Erics at home in is spare moment project. Eric has his hydrogen survey project. Plus he writes papers and grant requests, Along with whatever else he has going on at UCB. Dr. A has many brands in the fire also.
Matt has been on a quasi layoff because of budget restraints.
This project has been more reliable in the past year than ever before. Does it have a hiccup now and then? Yes it does. Thats why I have two backup projects when it does hit the fan.

---

[/quote]

Old James