Random crashes in 1.3 branch

[arseny]

Transmission (at least it's GTK+ interface) crashes randomly without any console diagnostic output, huge memory consumption or so. I can't understand what is a reason, I can't also recognize conditions causing crashes, but it's definitely regression from 1.2 branch and it's depends on GTK+ interface. As I can see crash can be happen if some of following conditions are present:

• intensive mouse (or keyboard) input in Transmission window;
• intensive memory operations on machine where Transmission is running;
• data of at least one torrent cannot be get.

I can perform regression testing if you get recommendations for me on doing it.

[muks]

If you are able to reproduce it, then the best thing to do is to run Transmission with debug info under gdb and get a backtrace. This will help us find out what is crashing.

Also, your report is not clear: does TR cause "huge memory consumption", or doesn't it?

[arseny]

Replying to muks:

If you are able to reproduce it, then the best thing to do is to run Transmission with debug info under gdb and get a backtrace. This will help us find out what is crashing.

The crashes are not regular, so it'll be hard to provide similar results. But I'll do it as soon as get some free time.

Also, your report is not clear: does TR cause "huge memory consumption", or doesn't it?

Not Transmission. Some task that I perform: computation of big math expression, for example. It takes big amount of memory, and TR crashes. My code hasn't memory leaks or wrong pointers. I'll test Transmission with Valgrind in addition to testing with gdb.

[arseny]

Replying to arseny:

TR seems to stop SEGFAULTing after updating glib to 2.16.6, but I want to spend more time for testing.

---

Current environment:

glibc 2.8_p20080602 (not released yet, but works fine)
gtk+ 2.12.12 and glib 2.12.6
gcc 4.3.1 with Gentoo patches (4.3.1-r1 p1.1)
TR is built without libnotify; compiler flags are -O3 -march=athlon-xp -mmmx
-msse -m3dnow -mfpmath=sse (too aggressive, I know) or just -O2;
it doesn't affect the result.
All my system is built with first set of gcc flags. It seems to be very stable.

[charles]

Does this persist in 1.34? This sounds a little bit like ticket #1278.

[arseny]

Replying to charles:

This sounds a little bit like ticket #1278.

I'm sure it's not the same. Here's backtrace for 1.33, but there was also at least one SEGFAULT. I'm going on watching.

[arseny]

caught SIGPIPE

[charles]

That 1.33 backtrace is just a side-effect of using Transmission in gdb.

When starting gdb, do this:

% gdb transmission (gdb) handle SIGPIPE nostop noprint nopass (gdb) r

[arseny]

Mark bug as invalid?

[charles]

okay. feel free to reopen if you get more information on non-SIGPIPE errors.