Fedora Core 2 client segfault on kernel 2.6.8

[rhoekstra]

Hi,

Just today I started up TS2 once again, which was fine while booting to kernels up to 2.6.7, and it gave me a segfault. I thought, well I've got another machine with FC2.. That machine as well just finished it's update job so also kernel 2.6.8 was installed, to which I was rebooting. After the reboot I fired up TS2 also gave me the same segfault :(

Okay I thought, just install it again... so I downloaded the latest client once again from the teamspeak.org site and started setup.sh with the following result:

------------
Runtime error 230 at 08062D1D
./setup.sh: line 19: 2741 Segmentation fault ${SETUPDIR}installer
------------

kinda similar to the error I got from the application itself (which I removed before taking the error line, sorry.

Anyone else experiencing the same? Perhaps it has nothing to do with the kernel but is some QT problem or so (is TS using QT?) because I saw some qt updates as well.

perhaps some environment setting can fix the thing... don't know..

Thanks in advance..

[mmaster]

I can confirm this. TS segfaults on the latest fedora core 2 kernel (2.6.8-1.521) but booting back into 2.6.7-1.494.2.2 works just fine.

I didn't reinstall the client or anything. I updated my kernel, found the segfault, rebooted into the previous version and it worked fine.


edit:
should mention that I applied a bunch of other updates at the same time. However, as stated, rebooting to the previous kernel version restored functionality.

[Brain]

Well, unless you absolutely need 2.6 you're better off using the latest 2.4 on production servers. There are still some child diseases being ironed out. When looking back there were always some more serious issues with kernel revisions that were in the single digits ;)

[rhoekstra]

Nah.. it's my own workstation, and FC2 happens to deliver kernel 2.6, which I use for some other testings... so it's no biggy.. just thought I'd let my voice heard.. Don't know if there's something to be done on the side of the developers (because of structural changes in the kernel perhaps?).

Hope to have it fixed soon though (say it a newer kernel version, or a newer TS client...)

Cheers.

[Brain]

Well, in 2.6.8 they somehow managed to break NFS which was quickly fixed with 2.6.8.1 - it looks to me they've currently gone swimming with the kernel, so it might be a very good idea to not use 2.6.8(.x) on production systems right now.

[mmaster]

this appears similar to the "It does nothing..." thread in this same forum.

I suggest that more than just fedora is causing segfaults on 2.6.8 kernels.

[cava]

the same happens to me
(FC2, kernel 2.6.8-1.521)

[mavit]

Just today I started up TS2 once again, which was fine while booting to kernels up to 2.6.7, and it gave me a segfault. I thought, well I've got another machine with FC2.. That machine as well just finished it's update job so also kernel 2.6.8 was installed, to which I was rebooting. After the reboot I fired up TS2 also gave me the same segfault :(
A workaround for this is to type, as root:echo 1 > /proc/sys/vm/legacy_va_layout
I wouldn't like to say if this a TeamSpeak or a kernel bug, but I imagine that the kernel people would be happy to help the TeamSpeak people sort it out one way or another.

[Rho]

This is a Fedora-specific issue, I believe. Both the client and the server exhibit this behavior on a Fedora 2.6.8 kernel (Quake 3 segfaults on this, too!), but they do not behave this way on a 2.6.8 kernel I downloaded from kernel.org and compiled.

[rhoekstra]

A workaround for this is to type, as root:echo 1 > /proc/sys/vm/legacy_va_layout
I wouldn't like to say if this a TeamSpeak or a kernel bug, but I imagine that the kernel people would be happy to help the TeamSpeak people sort it out one way or another.

Erm.. bummer... the 'file' doesn't exist... get an error when I try to write to it... (as root)

[HomeBrew]

I don't know if it's a kernal thing, a TS thing, or a combination of both, but the ./setup.sh script segfaulted under FC2 kernal 2.6.8-1.521, but worked perfectly when I rebooted and chose kernal 2.6.6-1.435.2.3...

[Thetargos]

I was just about to complaint on this too, and the echo trick did work. In my case, though it was the server the one who refused to start rather than the client, but the echo trick did it... So, for the time being I will add the echo statement to the /etc/rc.d/rc.local file while the problem gets addressed (BTW I haven't noticed this with the client on a 2.6.9-rc1-mm2 kernel).