Emule On Linux With Wine Mini-howto
Fresh and up-to-the-minute

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

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.

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

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

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

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)..

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.

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:

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

...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 ):

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

...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 ):

_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.

...
// 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

...
// 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.