Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[btkaos]

It would be really helpful if another dev could reproduce the bug and confirm it is reproducible indeed.

Setting the download limit to 0 doesn't really solve the issue on my side. Instead it seems to limit the probability of occurring. Ever since the OOM issue arised I kept the download limit at 0 and even so it still crashes from time to time. On much fewer occasions, but still it does.

Well that's one sample but it seems not the exact same bug, as I couldn't reproduce the bug when DL limit == 0. Still waiting for ^marcell^ to send me the exact conditions for reproducing that case.

I'll be more comfortable if either STU or Kry could reproduce it also.

[Kry]

One question, are you using 32 or 64bits ubuntu?

[Kry]

Ok, you have reaaaaaaaaally long addresses, so I'll assume 64.

[btkaos]

Ok, you have reaaaaaaaaally long addresses, so I'll assume 64.

Correct, running Ubuntu 10.10 64bits:

Code: [Select]

Linux xxx 2.6.35-26-generic #46-Ubuntu SMP Sun Jan 30 06:59:07 UTC 2011 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick


[Stu Redman]

It happens with 32 too.

[btkaos]

This is a weird bug Kry, in my testing the one behaving badly is glib, AFAICS amule does nothing wrong. glib gets in an infinite loop. The point is that a thing called "glib main context" gets corrupted. Of course neither wx or amule know that it even exists. How that can happen is really weird, as it is a global variable in glib.

Puzzling.

[Kry]

The thing is, I have actually seen it in a test application for a different bug I'm working on fixing inside wxWidgets/wxSocket. Infinite triggering of INPUT events from GTK. But I haven't been able to reproduce it in aMule yet.

I wouldn't worry too much about the glib main context being corrupted, to be honest with you. Who fucking knows what happens when the buildup of events starts breaking havok everywhere.

We may be looking at a glib/gtk bug, or a wxWidgets bug, or a combination of the two. But isn't it fun to investigate?

[Kry]

btkaos, I fixed another wx bug that was causing GTK events to be fired multiple times under certain conditions, or even after the socket is destroyed (causing a crash).

It's not exactly your problem, but please tell me if it makes a difference for you. Do not use my old patch from the previous post. Just apply this one, and tell me if it makes any difference.

The patch is GTK-specific and may break the ABI, so please recompile the entire wxWidgets after patching.

[btkaos]

Ok testing it now, in some minutes we'll know.

[Stu Redman]

Looking good if it is running and hasn't crashed yet. 

[btkaos]

Well, I let it run for one hour and it didn't crash (the cpu usage the donwload limit caused was huge)

Now I switched back to the unpatched library and amule did crash in 5 minutes, did another run and it went oom quite fast (it took about 15 minutes).

So far the patch seems to solve (or hide) the problem quite well, another question is how to propagate the fix to distribution users. Anyways I will test the patch for the whole before declaring it OK.

Now we should understand why glib failed without the patch, I can't tell whether glib or wx is to blame. From my understanding of glib code g_source_destroy should be thread safe, although this UNLOCK_CONTEXT in g_source_destroy_internal seems very suspicious.

Code: [Select]

     if (old_cb_funcs)
{
  UNLOCK_CONTEXT (context);
  old_cb_funcs->unref (old_cb_data);
  LOCK_CONTEXT (context);
}


[btkaos]

Anyways I will test the patch for the whole before declaring it OK.

whole night I mean. BTW, why can't I edit my posts anymore?

[Stu Redman]

Editing was disabled so that people can't slip in spam later. There was a time limit of like 20 min involved first which Kry has disabled it seems - can't say if intentionally.

[Kry]

You're a moderator now, you can edit posts. Use it carefully as you can edit other people's posts. Please don't, unless necessary.

There are a couple of things that wx without patch could cause, one of them is removing the same event token twice, which is obviously wrong. I don't know why that could cause problems. Also, two threads could call gtk_* functions at the same time, causing a crash as well.

The patch is not ready to be distributed to anyone. It has to be changed to wxMutex instead of pthread, and made compatible with the other ports to fix across the board. Once I ahve that done and in wx's svn, we can think of pestering distributions.

[btkaos]

There are a couple of things that wx without patch could cause, one of them is removing the same event token twice, which is obviously wrong. I don't know why that could cause problems. Also, two threads could call gtk_* functions at the same time, causing a crash as well.

The patch is not ready to be distributed to anyone. It has to be changed to wxMutex instead of pthread, and made compatible with the other ports to fix across the board. Once I ahve that done and in wx's svn, we can think of pestering distributions.

Well after some small analysis I think both wx and  glib are buggy. Under no circumstance should glib corrupt its context, and that indeed can happen if you look at the snippet of code I posted before. Of course if wx removes the same event token twice this is also a wx bug. Anyways the bug needs more investigation.

You're a moderator now, you can edit posts. Use it carefully as you can edit other people's posts. Please don't, unless necessary.

Ah ok thanks I don't mind doing some forum housekeeping in the crash/backtraces subforum like merging and moving topics, etc... but of course only if you allow it.