[Painkiller Jane]

Quote

Have you waited for, say, 10-15 minutes, then checked to see if the extra threads and memory were finally de-allocated? What you're experiencing may not even be a memory leak, just a slow de-allocation of resources which could be caused by any number of factors, including the particular Linux kernel you're using.

i've waited up to 2 hours. the additional thread and mem usage stay that long. no idea if there's an even more delayed de-allocation.

btw, when put under a little stress (20 files downloading, 5 files uploading) wine exits after a few hours giving various error messages 'could not allocate (file?)handle' and 'memory access error' being 2 of them.
the reason i've used my old (modified) 0.30e emule was that i'm sure that it runs WITHOUT any problems for WEEKS if not even months on a w2k box.
it's the most stable emule.exe i've ever used.

switching to a solution that besides the other problems (secID, browse dialog, graphical glitches) has serious stability issues too when used with the same settings as on w2k is definitely a no go.

maybe it runs a little longer with 'crippled' minimal settings but what's the point of that?

-pkj

This post has been edited by Painkiller Jane: 21 March 2004 - 02:33 PM

[mindpirate]

Painkiller Jane, on Mar 21 2004, 09:01 AM, said:

btw, when put under a little stress (20 files downloading, 5 files uploading) wine exits after a few hours giving various error messages 'could not allocate (file?)handle' and 'memory access error' being 2 of them.
the reason i've used my old (modified) 0.30e emule was that i'm sure that it runs WITHOUT any problems for WEEKS if not even months on a w2k box.
it's the most stable emule.exe i've ever used.

Yeah that's almost certainly a memory leak. If the same version of eMule runs fine under a real Windows environment then we can probably rule your eMule out as a possible culprit. The prime suspects would be the wineserver and your Linux kernel. Which version of Wine are you using (version, distro, and architecture), and which kernel?

This could also be a filesystem issue, and paging or journalling-related errors may be involved. By default SuSE has historically favored ReiserFS, but I haven't used ReiserFS for a couple of years now because I found it to be a bit sketchy and I continue to see reports from other users that it's still not totally sorted. I switched to EXT3 and haven't had any problems yet.

[Painkiller Jane]

i'm running SuSE 9.0 Kernel 2.4.21-192 on a intel P3 celeron 700mhz, 256mb box.
wine is version 20040309 compiled on the box.

filesystem is ReiserFS which made no problems so far but there's been no real stress on it before either.

i've just restarted wine/emule and used the webinterface. will monitor if there're any really bad delayed de-allocations (if wine runs long enough else i'll report the exact error message which wine spills when 'crashing'.)

-pkj

edit:
wine is alpha software and emule is, uhm, let's say work in progress. what are the chances that those combined run semi-stable, anyways?

This post has been edited by Painkiller Jane: 21 March 2004 - 03:19 PM

[Painkiller Jane]

approx. 1h10m later...

grrr, something new this time.
while mem usage for wine/emule was well below 50megs and overall system mem usage ~120 megs wine crashed saying:

Quote

_X11TransSocketOpen: socket() failed for local
_X11TransSocketOpenCOTSClient: Unable to open socket for local
_X11TransOpen: transport open failed for local/linux:0
x11drv: Can't open display: :0.0
Please ensure that your X server is running and that $DISPLAY is set correctly.
wine: Unhandled exception (thread 0009), starting debugger...

btw, i'm using XFree86 4.3.0.1-46 and kde 3.1.4.

WRT the 'additional' threads which my emule creates when logging out of the webinterface: they stayed till the crash using each ~500bytes physical and ~2.5megs virtual mem. but this still has to be determined as a wine bug since it's possible that win32 emule does exactly the same. i didn't use the webinterface on w2k often, so i never noticed anything odd with it's behaviour. when i have a little more time i'll look into it. or try a more recent release of emule with wine and check how that works.

anyways, just in case i also converted the reiserfs to ext3.

restarting wine/emule again...

-pkj

This post has been edited by Painkiller Jane: 21 March 2004 - 05:11 PM

[Painkiller Jane]

ok. next crash. same as above.
removed emule 0.30e and installed plain vanilla emule 0.42d.
1st try to login via the webinterface = crash. same error as above.
restart.
2nd try to use the webinterface = 1 additional thread and ~2.5 megs more used after log out. same as with 0.30e.

i'm beginning to suspect smth, though. i think wine doesn't deal too well with remotely (X-Win) connected users. 2 times wine crashed with that X11 no socket error while i tried to log in via X-Win or already have been logged in for some time. the remote session and other applications don't seem to be affected, though (i.e. there're X11 sockets available).

-pkj

edit: btw, with 0.42d wine says

Quote

WARNING: Trying to use ICMP (network ping) will fail unless running as root

i guess that ping is needed for the USS (i haven't enabled it).
could ultimately mean USS works only when running emule as root?
ouch.

This post has been edited by Painkiller Jane: 22 March 2004 - 01:00 AM

[tobiasthecommie]

well, the webinterface works fine , thats great, but for some reason i can't see any of the top buttons in emule42d. I can see the normal "connect" button for the normal ed2k network. And the rest of the network screen looks perfect(with the exception of the log box ofcourse)..

Does anyone have any idea what my button problem is?

Wee, this guide helped me alot.

Sincerly
Tobias Ussing
thehole@mail.seriesdb.com

[mindpirate]

Painkiller Jane, on Mar 21 2004, 07:44 PM, said:

i'm beginning to suspect smth, though. i think wine doesn't deal too well with remotely (X-Win) connected users. 2 times wine crashed with that X11 no socket error while i tried to log in via X-Win or already have been logged in for some time. the remote session and other applications don't seem to be affected, though (i.e. there're X11 sockets available).

Ah, I didn't know you were using remote X sessions. I agree, that could be one of your problems here. From what I've read in the Wine mailing list archives, that functionality in Wine is *very* alpha. Have you tried using it under just a local X session? I wonder how it would behave then.

Quote

edit: btw, with 0.42d wine says

Quote

WARNING: Trying to use ICMP (network ping) will fail unless running as root

i guess that ping is needed for the USS (i haven't enabled it).
could ultimately mean USS works only when running emule as root?
ouch.

Yeah I get that too. The typical Linux distro ships hardened against ICMP packet attacks, so this isn't a bug in eMule/Wine. You can either run eMule/Wine as root (a bad idea ) or make a couple of changes to your system config files to permit ICMP packets to/from your box under regular user accounts (a less bad idea ).

On the subject of uptimes, I've been running eMule under Wine for 16 hours straight now without fault, uploading and downloading at full blast. I've run it even longer under CrossOver but never thought to look at the uptime stats. So I've been unsuccessful in reproducing your crashes so far, though I'm using WinXP dll's and local X sessions only.

[mindpirate]

tobiasthecommie, on Mar 22 2004, 12:43 AM, said:

well, the webinterface works fine , thats great, but for some reason i can't see any of the top buttons in emule42d. I can see the normal "connect" button for the normal ed2k network. And the rest of the network screen looks perfect(with the exception of the log box ofcourse)..

If your toolbar is missing then there has been a mix-up with your comctl32.dll file.

First make sure you have copied the Windows XP version of comctl32.dll to your emulated Windows system directory (by default, ~/.wine/fake_windows/Windows/System). If you've copied it from your Windows XP CD-ROM, make sure you've renamed it to comctl32.dll after copying it over because it's called comctl32.dl_ on the CD.

Next double-check your ~/.wine/config file and make sure in the [Version] section you have:

"Windows" = "winxp"

then down at the bottom before the line:

# [/wineconf]

make sure it reads this exactly:

;; eMule
[AppDefaults\\emule.exe\\DllOverrides]
"*" = "builtin, native"
"comctl32" = "native"
"riched20" = "native"

If any of this had to be changed, then you may need to reinstall eMule (instructions for this are in the HOWTO).

If you still have the problem let me know, and please tell me your Linux setup, Wine version, etc.

[Painkiller Jane]

Quote

Have you tried using it under just a local X session? I wonder how it would behave then.

i started emule 0.30e in a local session several times, but used remote x-sessions to check if it's still running. those locally started emules ran ~3-4 hours until closing with mem access or out of handle errors.

i'm trying 0.42d now, locally started and will not use webinterface nor remote x-sessions. let's see if there's much of a difference.

next thing to do is to aquire winxp dlls to mimic your setup as good as possible?
hope my brother still has that piece of crap somewhere around.

-pkj

This post has been edited by Painkiller Jane: 22 March 2004 - 03:27 PM

[Painkiller Jane]

btw

Quote

...copy it from your Windows XP CD-ROM, make sure you've renamed it to comctl32.dll after copying it over because it's called comctl32.dl_ on the CD.

i found the .DL_ files on my xp cd to be compressed which wine of course can't load if they're only renamed.
ms uses those compressed .DL_ .EX_ etc files since ms dos times and also since then there's a tool called expand.exe (in i386 dir) which decompresses them.

so proper way to get the .DL_ files ready for wine is:
copy expand.exe, comctl32.dl_ and riched20.dl_ from the xp cd (/i386 dir) to a temp dir (on a windows machine! ).
open a commandline prompt ('dos' prompt) and cd into your temp dir.
run (type then hit enter ):

expand comctl32.dl_ comctl32.dll
expand riched20.dl_ riched20.dll

copy riched20.dll and comctl32.dll from you temp dir to your wine system dir, adjust wine config file.

having that said, the linux box is freshly rebooted, the mount emule works on is ext3. the emule version is 0.42d running with default settings. wine 'emulates' winxp with winxp dlls. i won't use remote sessions nor the webinterface.

waiting for a crash...

-pkj

edit: are you running kde? i'm thinking of running wine/emule on plain fvwm2 or such if it crahes again spilling X11 socket errors.

This post has been edited by Painkiller Jane: 22 March 2004 - 03:36 PM

[mindpirate]

Painkiller Jane, on Mar 22 2004, 10:17 AM, said:

btw

Quote

...copy it from your Windows XP CD-ROM, make sure you've renamed it to comctl32.dll after copying it over because it's called comctl32.dl_ on the CD.

i found the .DL_ files on my xp cd to be compressed which wine of course can't load if they're only renamed.
ms uses those compressed .DL_ .EX_ etc files since ms dos times and also since then there's a tool called expand.exe (in i386 dir) which decompresses them.

so proper way to get the .DL_ files ready for wine is:
copy expand.exe, comctl32.dl_ and riched20.dl_ from the xp cd (/i386 dir) to a temp dir (on a windows machine! ).
open a commandline prompt ('dos' prompt) and cd into your temp dir.
run (type then hit enter ):

expand comctl32.dl_ comctl32.dll
expand riched20.dl_ riched20.dll

copy riched20.dll and comctl32.dll to your wine system dir, adjust wine config file.

Oops, you're right, they're still compressed even though they're not in a CAB file. Thanks for the correction.

Well, that being the case, there's a more elegant solution to extract the dll's without having to boot into Windows: the GNU cabextract command that ships with most Linux distros.

Open a console, change to the i386 directory on the WinXP CD, then enter:

cabextract -d ~/.wine/fake_windows/Windows/System comctl32.dl_ riched20.dl_

The dll's are extracted, copied to the correct location for Wine, and automatically renamed to comctl32.dll and riched20.dll, respectively.

For good measure, I'll add both the DOS extract and GNU cabextract methods to the howto.

@ tobiasthecommie: Make note of this if you're copying those files from CD.

[mindpirate]

mindpirate, on Mar 22 2004, 10:45 AM, said:

Well, that being the case, there's a more elegant solution to extract the dll's without having to boot into Windows: the GNU cabextract command that ships with most Linux distros.

Minor correction: cabextract is non-GNU, but is GPL:

http://www.kyz.uklin.../cabextract.php

On the SuSE CD's the package name is cabextract. Probably the same with the other major distros as well.

[mindpirate]

Damn, eMule just crashed after 18 hours of continuous (and heavy) usage.

The same error you got also showed up:

_X11TransSocketOpen: socket() failed for local
_X11TransSocketOpenCOTSClient: Unable to open socket for local
_X11TransOpen: transport open failed for local/asimov:0
x11drv: Can't open display: :0
Please ensure that your X server is running and that $DISPLAY is set correctly.

but it would seem these messages are simply the result of eMule and Wine crashing before one or more Wine-related X server operations was able to complete, as it looks like a callback from the X server failed.

My crash occurred immediately after a 350 MB file finished downloading. I'm not sure if it bailed during the hash verification or after. So the crash could be hash or disk-access related. You might want to keep an eye on your files when they get close to completion and see if that's when your crashes are happening.

All Wine processes and their threads died and all memory was released immediately after the crash, and memory usage until then seemed normal, so I'm still not seeing any evidence of memory leaks on my setup.

[Painkiller Jane]

hrm, my emule survived completing 3 files so far (sizes ranging from 175 to 460 megs). crashes didn't seem related to finishing files. but i keep an eye on it.

i'm wondering what the _X11TransSocket... stuff does?

maybe wine/X11 is a little too stressed with all the GDCs emule uses (progressbars and such)? maybe switching off the progressbars helps.

This post has been edited by Painkiller Jane: 26 March 2004 - 07:54 AM

[tobiasthecommie]

hehe, stupid me, i just used a comctl32.dll i had lying around, i didn't grap the windows xp one. well, did now, orking like a charm.

and i also put it in the windows dir first time around. stupid me .

Well, thanks for all your help.

Sincerly
Tobias Ussing
thehole@mail.seriesdb.com <- in case your wondering why i put this, its for spam bots to pick up, i catch it for analysis.

[mindpirate]

Painkiller Jane, on Mar 22 2004, 12:56 PM, said:

i'm wondering what the  _X11TransSocket... stuff does?

Guess I'll peek at the Wine source code to make sure.

Quote

maybe wine/X11 is a little too stressed with all the GDCs emule uses (progressbars and such)? maybe switching of the progressbars helps.

That seems possible. Time to scour the Wine archives again I guess.

[mindpirate]

tobiasthecommie, on Mar 22 2004, 01:02 PM, said:

hehe, stupid me, i just used a comctl32.dll i had lying around, i didn't grap the windows xp one. well, did now, orking like a charm.

and i also put it in the windows dir first time around. stupid me .

Well, thanks for all your help.

Groovy.

Please report any other problems you run into, even if it's something already reported in this thread.

Realistically I don't expect eMule/Wine to work for everyone, but I'm hoping we can improve it so that Linux users in general will have a viable alternative choice when it comes to ED2K clients.

[Painkiller Jane]

hrmpf!

crypto++ 5.1 - config.h

Quote

...
// define this if you want to disable all OS-dependent features,
// such as sockets and OS-provided random number generators
//#define NO_OS_DEPENDENCE

// Define this to use features provided by Microsoft's CryptoAPI.
// Currently the only feature used is random number generation.
// This macro will be ignored if NO_OS_DEPENDENCE is defined.
#define USE_MS_CRYPTOAPI
...

... and of course if one undefs USE_MS_CRYPTOAPI the crap won't compile without errors anymore. will see if i can make that work. maybe we end up with an emule which doesn't need those calls to ms crypt api anymore.

-pkj

This post has been edited by Painkiller Jane: 22 March 2004 - 08:13 PM

[mindpirate]

Painkiller Jane, on Mar 22 2004, 03:06 PM, said:

hrmpf!

crypto++ 5.1 - config.h

Quote

...
// define this if you want to disable all OS-dependent features,
// such as sockets and OS-provided random number generators
//#define NO_OS_DEPENDENCE

// Define this to use features provided by Microsoft's CryptoAPI.
// Currently the only feature used is random number generation.
// This macro will be ignored if NO_OS_DEPENDENCE is defined.
#define USE_MS_CRYPTOAPI
...

... and of course if one undefs USE_MS_CRYPTOAPI the crap won't compile without errors anymore. will see if i can make that work. maybe we end up with an emule which doesn't need those calls to ms crypt api anymore.

I'm not sure if secure user ID will work at all if you remove the Windows bindings there. It's worth a try I suppose. If it works, great, but unfortunately I won't be able to use that particular solution in the howto because I designed the howto to be newbie friendly and hence compiling eMule is excluded.

[mindpirate]

I just updated the howto at the beginning of this thread. Several significant changes were made, including the instructions for extracting the dll files.