The 32 bit linux version isn't working for me, all tasks die with "process got signal 11". An example WU:

http://stat.la.asu.edu/NumberFields/result.php?resultid=904465


<core_client_version>5.10.45</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>

</stderr_txt>
]]>


Not enough of a linux expert to offer much help. Maybe I got the 64-bit verion or something?

Cheers,

Al.

I just verified that you are definitely running the 32 bit version. There is 1 other user who is also getting compute errors, but it's a different error.

If you could, try running the GetDecics app and see if you still have the problem. There are multiple users who are returning successful 32bit results for that app. For the GetBoundedDecics app, my virtual machine is the only one that's returned a successful result so far (but that might just be a coincidence).

The 32 bit linux version isn't working for me, all tasks die with "process got signal 11". An example WU:

http://stat.la.asu.edu/NumberFields/result.php?resultid=904465


5.10.45

process got signal 11




]]>


Not enough of a linux expert to offer much help. Maybe I got the 64-bit verion or something?

Cheers,

Al.

This link may give some hints:

http://boincfaq.mundayweb.com/index.php?view=459&language=1

So far you are the only one with the signal 11 problem, but there are also very few users running the 32bit linux version of BoundedDecics.

Yeah, I was aware that it was a segmentation error - I've seen numerous threads on other project fora about it ;)

Not worth me trying to run the unbounded app on such a slow machine :(

Hopefully someone else can try out the bounded app and have more success than me, or at least be able to debug it if it fails for them.

Cheers,

Al.

Yeah, I was aware that it was a segmentation error - I've seen numerous threads on other project fora about it ;)

Not worth me trying to run the unbounded app on such a slow machine :(

Hopefully someone else can try out the bounded app and have more success than me, or at least be able to debug it if it fails for them.

Cheers,

Al.

There's only about 40 of the slow unbounded WUs left and they are all currently "in progress", so you don't have to worry about getting one of those. The other unbounded Wus are much more reasonable.

There's only about 40 of the slow unbounded WUs left and they are all currently "in progress", so you don't have to worry about getting one of those. The other unbounded Wus are much more reasonable.

Not an absolute certainty, I'm afraid - I got this resend overnight.

But if somebody with a slower machine happened, by some remote unlucky chance, to pick up a task named "wu_DS-14x121_...", I don't think anybody would be offended if you aborted it in the hope of picking up a shorter one next time - it would just go back into the resend pool and hopefully be picked up by a faster machine.

I've bumped mine to run next, in the hope we can get rid of these pesky blighters once and for all.

Not an absolute certainty, I'm afraid - I got this resend overnight.

But if somebody with a slower machine happened, by some remote unlucky chance, to pick up a task named "wu_DS-14x121_...", I don't think anybody would be offended if you aborted it in the hope of picking up a shorter one next time - it would just go back into the resend pool and hopefully be picked up by a faster machine.

I've bumped mine to run next, in the hope we can get rid of these pesky blighters once and for all.

LOL. Yes, it will be nice once these pesky WUs are finally gone.

The accelerating retries mechanism was turned back on a couple weeks ago, and all the remaining pesky WUs have been issued to "reliable" hosts. So hopefully it won't be much longer.

Well, it works fine on my Ubuntu computer.
I had a bit of a shock when my first work unit jumped to 100% after 3 seconds and I thought it had crashed, but it had simply finished correctly, and was a valid result!
I'll do a few more to make sure everything is working properly.

WUs that fast are not very common, but I do see them occasionally. Thanks for checking it out.

Yeah, I was aware that it was a segmentation error - I've seen numerous threads on other project fora about it ;)

Not worth me trying to run the unbounded app on such a slow machine :(

Hopefully someone else can try out the bounded app and have more success than me, or at least be able to debug it if it fails for them.

Cheers,

Al.

Hey Al,

I just checked and there are now 2 users who have returned successful results for the GetBoundedDecics app. So far you are the only one getting the signal 11 error.

Just for the record, there is another user with this problem:
http://numberfields.asu.edu/NumberFields/forum_thread.php?id=66&nowrap=true#600
But this should be independent of the signal 11 error.

I also read that sometimes doing a project reset can fix this. You might give that a try.