Crashes /lib/libc.so.6

[Bonaparte]

I've got random crashes on Ubuntu 10.04

uname -a

Linux username 2.6.18-194.8.1.el5.028stab070.4 #1 SMP Tue Aug 17 19:11:52 MSD 2010 i686 GNU/Linux

I don't know how to reproduce it. It happens with more than 20 torrents active and when files with cyrillic names are seeded (not sure, crashes are random ).

gdb shows such message every time:

Program received signal SIGABRT, Aborted.

[switching to Thread 0xb7e2ab70 (LWP 31838)]

0xb7e56607 in raise () from /lib/libc.so.6

[DreadWingKnight]

cyrillic names are a known issue at the current time.

[Bonaparte]

more info:

(gdb) bt

#0 0xb7e56607 in raise () from /lib/libc.so.6

#1 0xb7e59ab2 in abort () from /lib/libc.so.6

#2 0x080ca7d3 in WarnNoMemory(unsigned int) ()

#3 0x08088e6b in MyMalloc(unsigned int) ()

#4 0x0809b92e in PeerConnection::ParsePacket() ()

#5 0x0809c676 in PeerConnection::run_state() ()

#6 0x08090974 in TcpSocket::loop() ()

#7 0x080904e8 in Socket::NetworkLoop(long) ()

#8 0x080906bd in Socket::NetworkEventLoop(ThreadSync*) ()

#9 0x08090733 in NetworkThread(void*) ()

#10 0x080b9e2b in thread_func_wrapper(void*) ()

#11 0xb7fc97f0 in start_thread () from /lib/libpthread.so.0

#12 0x00000002 in ?? ()

#13 0x00000002 in ?? ()

#14 0x00000002 in ?? ()

#15 0xb6e2a444 in ?? ()

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

WarnNoMemory means that uT didn't found enough memory?

I limited memory consumption with ulimit -v 900000

[mcdonald]

#0 0xb7e56607 in raise () from /lib/libc.so.6

#1 0xb7e59ab2 in abort () from /lib/libc.so.6

#2 0x080ca7d3 in WarnNoMemory(unsigned int) ()

WarnNoMemory means that uT didn't found enough memory?

I limited memory consumption with ulimit -v 900000

The times that I recall seeing this sort of backtrace have resulted in me finding heap corruptions. It isn't the lack of memory as one would think from the function name, but rather the inability of the heap code to find a suitable block because the heap is corrupted. That's my guess.

Are any of these torrents downloading or are they all seeding?

Are any of the torrents larger than 4GB?

Someone just fixed some issues with large seeding torrents, so I'm wondering if these are showing up here.

[mcdonald]

cyrillic names are a known issue at the current time.

This could be a problem here. It would be worthwhile to exclude cyrillic names to see.

[Bonaparte]

I tried 1 active torrent (mp3-discography, total size 4,23 Gb, cyrillic names present).

Yep, uTorrent crashes in 1-2 minutes, the problem is reproducible in this case.

With cyrillic names and smaller torrents crashes still happen but after longer time (5-10 minutes).

Also I've got weird behaviour: with some cyrillic files the program is still stable when they are either downloading or seeding. But after adding new torrent with latin name crash occures.

With exclusion non-latin names the program is working ok for a few hours already, it's good result. BUT a tracker continued to show stopped cyrillic torrents as active for a couple of hours (!)

-------- I have no private data on my seedbox so I can get you ssh access to locate a problem.

[Bonaparte]

Well, at night uTorrent crashed again

There were no torrents with cyrillic names or larger than 4 Gb.

All files were seeding.

gdb error message is the same:

Program received signal SIGABRT, Aborted.

[switching to Thread 0xb7e2ab70 (LWP 9325)]

0xb7e56607 in raise () from /lib/libc.so.6

(gdb) bt

#0 0xb7e56607 in raise () from /lib/libc.so.6

#1 0xb7e59ab2 in abort () from /lib/libc.so.6

#2 0x080ca7d3 in WarnNoMemory(unsigned int) ()

#3 0x08088e6b in MyMalloc(unsigned int) ()

#4 0x0809d521 in AllocatePieceCache(FileStorage*, unsigned int, unsigned int)

()

#5 0x080766f7 in DiskIO::ReadJob::Perform() ()

#6 0x08075af1 in ProcessJobList(DiskIO::Job*) ()

#7 0x08077eb1 in IOThread(void*) ()

#8 0x080b9e2b in thread_func_wrapper(void*) ()

#9 0xb7fc97f0 in start_thread () from /lib/libpthread.so.0

#10 0x00000002 in ?? ()

#11 0x00000002 in ?? ()

#12 0x00000002 in ?? ()

#13 0xb7e2a444 in ?? ()

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The program crashes sooner if I add new torrent with dots in file names.

[mcdonald]

With exclusion non-latin names the program is working ok for a few hours already, it's good result. BUT a tracker continued to show stopped cyrillic torrents as active for a couple of hours (!)

-------- I have no private data on my seedbox so I can get you ssh access to locate a problem.

Thanks for the offer. I'd like to try something else first. Can you send me a list of the URLs to the torrent files that you are using to reproduce the problem (the ones with non-Cyrillic named files)? Via post or PM is OK. I'd like to try to reproduce the problem here. Do you only see it seeding, and is that only because you already have the data files and haven't tried downloading them?

[mcdonald]

Well, at night uTorrent crashed again

There were no torrents with cyrillic names or larger than 4 Gb.

All files were seeding.

gdb error message is the same:

Program received signal SIGABRT, Aborted.

[switching to Thread 0xb7e2ab70 (LWP 9325)]

0xb7e56607 in raise () from /lib/libc.so.6

(gdb) bt

#0 0xb7e56607 in raise () from /lib/libc.so.6

#1 0xb7e59ab2 in abort () from /lib/libc.so.6

#2 0x080ca7d3 in WarnNoMemory(unsigned int) ()

#3 0x08088e6b in MyMalloc(unsigned int) ()

Looks consistent with a heap corruption. The common point is when some attempt to allocate heap fails because the internal heap management data is corrupted. In a multi-threaded program it can be difficult to determine the cause because the activity being performed at the point at which the crash occurs is often not responsible for creating the problem.