SB v1.0.1 for linux/bsd/beos out

[Alien88]

Good news all. V1.0.1 for Linux, FreeBSD and BeOS is now out for you to download. This should fix the problems with the client crashing that some people are experiencing.

There will not be a windows release for this version as it is only bugfixes for the linux/bsd/beos code.

If you experience any problems with this client, please post here. Also, if it does crash please run gdb core sb and then type bt and paste the output out.

-Alien88

[shifted]

I've been running it for a little bit, and so far so good :)

[SurGreen]

New version worx.. Thank you [ whomsoever that may be exactly ] ............. However, I am unable to set the priority to IDLE via ProcessController as had been suggested. :/ Any advice , etc most APPRECIATED :)

[shifted]

Originally posted by SurGreen
New version worx.. Thank you [ whomsoever that may be exactly ] ............. However, I am unable to set the priority to IDLE via ProcessController as had been suggested. :/ Any advice , etc most APPRECIATED :)

Since this is a topic about an update to the unix client, I can try to help. Open the sclient.conf file in your favourite editor. There should be an item in there called PriorityLevel n, where n is the process priority from 1 to 5. Set it 5 and restart the client.

[res0r9lm]

Still getting seg faults :(

[Fri Nov 22 06:04:30 2002] residue: DCF49D2E2EFAAEA1
[Fri Nov 22 06:04:30 2002] completed proth test(k=33661, n=1106808): result 3
[Fri Nov 22 06:04:30 2002] connecting to server
Segmentation fault

[gbusler]

Sorry to say that I got another segfault with the v1.0.1 linux client. Backtrace is below.

(gdb) bt
#0 0x0805ff6c in chunk_free (ar_ptr=0x80c8e60, p=0xd4f07684) at malloc.c:3225
#1 0x080626c9 in __libc_free (mem=0x824aec0) at malloc.c:3154
#2 0x0804f4c0 in term_giants ()
#3 0x0805600b in isProthPRP ()
#4 0x08056b2b in block_loop ()
#5 0x080568ce in main ()
#6 0x08059f02 in __libc_start_main (main=0x8056750 <main>, argc=2, ubp_av=0xbffff9a4,
init=0x80480b4 <_init>, fini=0x80a9760 <_fini>, rtld_fini=0, stack_end=0xbffff99c)
at ../sysdeps/generic/libc-start.c:129
(gdb)

also noticed another little oddity the residue line was printed to screen just before the segfault, you can see from below that the residue is different for the same completed test. Is that suppose to happen or are these segfault invalidating all of the work that we've been doing on the non-Windows oses since v0.9.8's come out.

[Fri Nov 22 05:03:56 2002] iteration: 1100000/1101064 (99.90%) k = 33661 n = 1101048
[Fri Nov 22 05:04:23 2002] residue: 12A23C9096824843
Segmentation fault (core dumped)

[Fri Nov 22 06:27:04 2002] iteration: 1100000/1101064 (99.90%) k = 33661 n = 1101048
[Fri Nov 22 06:27:18 2002] residue: 7E0EC56A04CFAFF9

Grant

[SurGreen]

Thanx for noticing :)

.... but as was mentioned in the remarks for the BeOS client.............. not yet functioning as a BeOS option. IDLE=0 in BeOS 5= NORMAL thus I feel this may be a Be-coder issue.......... but thanks HEAPS ......... it is ALL GOOD!! :) .. apart from that .. i dunno!! I am a beginner tech NOT a coder .........

[shifted]

Originally posted by SurGreen
Thanx for noticing :)

.... but as was mentioned in the remarks for the BeOS client.............. not yet functioning as a BeOS option. IDLE=0 in BeOS 5= NORMAL thus I feel this may be a Be-coder issue.......... but thanks HEAPS ......... it is ALL GOOD!! :) .. apart from that .. i dunno!! I am a beginner tech NOT a coder .........

Hmm... it's been so long since i used BeOS. Try reading up on the renice command. (If you don't know how, open a terminal and type man renice to get the manual.)

[shifted]

I also got a seg fault. I just figured out how to re-enable core files, but i'll have to wait for it to crash once more to collect them.

[smh]

also noticed another little oddity the residue line was printed to screen just before the segfault, you can see from below that the residue is different for the same completed test. Is that suppose to happen or are these segfault invalidating all of the work that we've been doing on the non-Windows oses since v0.9.8's come out.

[Fri Nov 22 05:03:56 2002] iteration: 1100000/1101064 (99.90%) k = 33661 n = 1101048
[Fri Nov 22 05:04:23 2002] residue: 12A23C9096824843
Segmentation fault (core dumped)

[Fri Nov 22 06:27:04 2002] iteration: 1100000/1101064 (99.90%) k = 33661 n = 1101048
[Fri Nov 22 06:27:18 2002] residue: 7E0EC56A04CFAFF9


That makes me worried :(

i think at least ALL the numbers tested that got a segfault have to be double checked. But this shows even more that ALL numbers need to be double checked.

Not the most pleasant job, but i guess that slower clients can do this when N gets too high for all the remaining numbers.

[gbusler]

Another backtrace from segfault'ed linux v1.0.1 client. It is in another part of the code so decided to post it.

(gdb) bt
#0 0x0805ff6c in chunk_free (ar_ptr=0x80c8e60, p=0xdaf7815b) at malloc.c:3225
#1 0x0805f87e in chunk_alloc (ar_ptr=0x80c8e60, nb=1608) at malloc.c:2706
#2 0x0805f351 in __libc_malloc (bytes=1600) at malloc.c:2811
#3 0x0805149d in popg ()
#4 0x0805549e in write_gwnum ()
#5 0x0805563a in writeToFile ()
#6 0x08055f05 in isProthPRP ()
#7 0x08056b2b in block_loop ()
#8 0x080568ce in main ()
#9 0x08059f02 in __libc_start_main (main=0x8056750 <main>, argc=2, ubp_av=0xbffff9a4,
init=0x80480b4 <_init>, fini=0x80a9760 <_fini>, rtld_fini=0, stack_end=0xbffff99c)
at ../sysdeps/generic/libc-start.c:129
(gdb) q

Grant

[jjjjL]

the linux client problem is so weird.

different residues is definately not suppose to happen. i also have no idea how that could happen or how it would be related to the seg fault. if you see that again, especially on another computer, that would be bad. for now i'd chalk it up to a random computational failure. check that puter out.

the real weird part about it is i no longer get seg faults on a single one of my 22 linux computers or my BeOS one which i compiled with debug codes. as with all seg faults, it's going to turn out to be something completely pointless and infuriating. there is also no reason why the windows client shouldn't have memory errors too but it has never died on a computer yet except for ones that later turned out to have hardware issues. go figure. probably because windows just has no memory protection and linux does.

oh well. i'll work on it again next week. if anyone knows of any good gnu dev tools to analyze code and help me find the execution path causing this, feel free to let me know.

-Louie

[Alien88]

Originally posted by jjjjL
the linux client problem is so weird.

different residues is definately not suppose to happen. i also have no idea how that could happen or how it would be related to the seg fault. if you see that again, especially on another computer, that would be bad. for now i'd chalk it up to a random computational failure. check that puter out.

the real weird part about it is i no longer get seg faults on a single one of my 22 linux computers or my BeOS one which i compiled with debug codes. as with all seg faults, it's going to turn out to be something completely pointless and infuriating. there is also no reason why the windows client shouldn't have memory errors too but it has never died on a computer yet except for ones that later turned out to have hardware issues. go figure. probably because windows just has no memory protection and linux does.

oh well. i'll work on it again next week. if anyone knows of any good gnu dev tools to analyze code and help me find the execution path causing this, feel free to let me know.

-Louie

I haven't got a diff residual yet.. so that's odd to me too

[shifted]

I haven't compared residues, but I had two more seg faults in the last 12 hours. Just got home now. Both were on seperate machines, on which i have had no problems with running at 100% cpu before (other projects).

[moooooooo]

BeOS users:
get TManager from BeBits
http://www.bebits.com/app/434
click on the sb process and you can set the priority that way.
The default is 10 which slows the PC down somewhat, but if you make it 5 then you get a nice trade off.

Lower numbers = less priority
cheers
peter

[_V_]

Setting the client to idle (0) seems impossible (with Processcontroller), but setting it to 1 is not. You have to admit 1 is still a pretty low priority ;)

[Chinasaur]

Louie,

I have five BeOS clients running now. Two duals.

Any idea how the Be client stacks up against the others speed wise? Be clients have historically lagged behind other clients but SoB seems to run as fast on Be as other clients.

TIA. :cheers:

[SurGreen]

Thanks everyone that offered advice on setting my priority. Have finally set it down with some help from Beyond on TheBeOSJournal forum.

Really appreciate all the suggestions though :)