[mindpirate]

pjv3, on Jun 18 2006, 01:23 AM, said:

I'll try to log something at winehq, however, I note that these problems with wine + emule have been listed here since 2004, so it doesn't look like a high priority. 

Yeah, and you'll notice they still haven't bumped the severity of Bug 3063 - emule exposes socket/file handle leak up to "critical" as requested (and a bug that repeatedly results in a crash is a critical bug). Seems the Wine devs aren't paying attention, so perhaps you should open a new bug for your issue and as justification it should mention that the older bug hasn't been marked "critical". This way if some Wine dev marks the new bug a dupe, at least they'll be forced to deal with updating the severity of the older bug.

[fabtar]

I have tested emule 47a on debian "testing" wine 9.15.
Emule starts well, panel and configurations works...
Conencts to servers and to Kad
starting a new download, after few seconds the application crashes .. there are only abunch of numbers in the console...the first try emule seems to keep running(only interface seems disapperaed) , the second time the emule.exe/wine crashes completely.
I'm sorry about not having here the complete output, but I have done at home on antoher PC.
I fear is something strange in debian's wine packages.

wine is in w2k modality
emule too

cheeers

[fabtar]

I have already heard about this unimplemented dnsapi.. I thought this is solved...
Here is my Console's output.
Perhaps wine's debain package is not so good.

 WineDbg starting on pid 0xc
Unhandled exception: unimplemented function dnsapi.dll.DnsQueryConfig called in 32-bit code (0x7fc89f52).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:135f GS:0033
 EIP:7fc89f52 ESP:7d88a8a4 EBP:7d88a908 EFLAGS:00200246(   - 00      - IZP1)
 EAX:7fc73cb1 EBX:7fcf48bc ECX:00000000 EDX:00000008
 ESI:7d88a934 EDI:7d88a8c8
Stack dump:
0x7d88a8a4:  0070a498 7d88a8d8 80000100 00000001
0x7d88a8b4:  00000000 7fc89e90 00000002 7d529570
0x7d88a8c4:  7d529cec 00000057 7bea986f 7d88a940
0x7d88a8d4:  7bef579c 7d88a918 7beb9f5d 7befd284
0x7d88a8e4:  ffffffff 00000000 7d88a908 00000000
0x7d88a8f4:  00000000 7befd284 7d52b6c4 00000000
026b: sel=135f base=7dd6c000 limit=00001fff 32-bit rw-
Backtrace:
=>1 0x7fc89f52 RaiseException+0xc2 in kernel32 (0x7fc89f52)
  2 0x7d529503 in dnsapi (+0x9503) (0x7d529503)
  3 0x7d528887 in dnsapi (+0x8887) (0x7d528887)
fixme:dbghelp:sffip_cb NIY on 'e:\eclipse302\workspace\srchybrid\release\emule.p db'
  4 0x0048200e in emule (+0x8200e) (0x0048200e)
  5 0x006495ab in emule (+0x2495ab) (0x006495ab)
  6 0x7fcd56ef in kernel32 (+0x756ef) (0x7fcd56ef)
  7 0x7bedb0fa in ntdll (+0x4b0fa) (0x7bedb0fa)
  8 0xb7ed3e60 start_thread+0x80 in libpthread.so.0 (0xb7ed3e60)
  9 0xb7e678ee __clone+0x5e in libc.so.6 (0xb7e678ee)
0x7fc89f52 RaiseException+0xc2 in kernel32: movl        0xfffffff4(%ebp),%ebx
Modules:
Module  Address                 Debug info      Name (117 modules)
PE      0x00400000-00ac5000     Export          emule
PE      0x10000000-1001b000     Deferred        it_it
ELF     0x7be82000-7bf00000     Export          ntdll<elf>
  \-PE  0x7be90000-7bf00000     \               ntdll
ELF     0x7bf00000-7bf03000     Deferred        <wine-loader>
ELF     0x7d4cb000-7d500000     Deferred        rsaenh<elf>
  \-PE  0x7d4d0000-7d500000     \               rsaenh
ELF     0x7d516000-7d52d000     Export          dnsapi<elf>
  \-PE  0x7d520000-7d52d000     \               dnsapi
ELF     0x7d53d000-7d550000     Deferred        libresolv.so.2
ELF     0x7dd78000-7dd7e000     Deferred        libnss_dns.so.2
ELF     0x7dd7f000-7dd87000     Deferred        libungif.so.4
ELF     0x7dd94000-7ddb4000     Deferred        libjpeg.so.62
ELF     0x7ddb4000-7ddc9000     Deferred        icmp<elf>
  \-PE  0x7ddc0000-7ddc9000     \               icmp
ELF     0x7dfef000-7e003000     Deferred        msimg32<elf>
  \-PE  0x7e000000-7e003000     \               msimg32
ELF     0x7e003000-7e017000     Deferred        lz32<elf>
  \-PE  0x7e010000-7e017000     \               lz32
ELF     0x7e017000-7e030000     Deferred        version<elf>
  \-PE  0x7e020000-7e030000     \               version
ELF     0x7e148000-7e190000     Deferred        riched20<elf>
  \-PE  0x7e160000-7e190000     \               riched20
ELF     0x7e2a3000-7e2a6000     Deferred        iso8859-1.so
ELF     0x7e2af000-7e394000     Deferred        libdb-4.3.so
ELF     0x7e394000-7e3e2000     Deferred        libgcrypt.so.11
ELF     0x7e3e2000-7e44f000     Deferred        libgnutls.so.12
ELF     0x7e44f000-7e46b000     Deferred        libcups.so.2
ELF     0x7e46b000-7e480000     Deferred        midimap<elf>
  \-PE  0x7e470000-7e480000     \               midimap
ELF     0x7e597000-7e5bd000     Deferred        msacm32<elf>
  \-PE  0x7e5a0000-7e5bd000     \               msacm32
ELF     0x7e5bd000-7e5d5000     Deferred        msacm<elf>
  \-PE  0x7e5c0000-7e5d5000     \               msacm
ELF     0x7e5d5000-7e697000     Deferred        libasound.so.2
ELF     0x7e697000-7e6c0000     Deferred        winealsa<elf>
  \-PE  0x7e6a0000-7e6c0000     \               winealsa
ELF     0x7e700000-7e710000     Deferred        libtasn1.so.2
ELF     0x7e727000-7e759000     Deferred        uxtheme<elf>
  \-PE  0x7e730000-7e759000     \               uxtheme
ELF     0x7e759000-7e775000     Deferred        imm32<elf>
  \-PE  0x7e760000-7e775000     \               imm32
ELF     0x7e775000-7e792000     Deferred        ximcp.so.2
ELF     0x7e792000-7e79b000     Deferred        libxrender.so.1
ELF     0x7e833000-7ef84000     Deferred        libglcore.so.1
ELF     0x7ef84000-7effc000     Deferred        libgl.so.1
ELF     0x7effc000-7f0c7000     Deferred        libx11.so.6
ELF     0x7f0c7000-7f0df000     Deferred        libice.so.6
ELF     0x7f0df000-7f0e8000     Deferred        libsm.so.6
ELF     0x7f0ec000-7f0f1000     Deferred        libnss_db.so.2
ELF     0x7f0f1000-7f0f5000     Deferred        libgpg-error.so.0
ELF     0x7f0ff000-7f184000     Deferred        winex11<elf>
  \-PE  0x7f110000-7f184000     \               winex11
ELF     0x7f184000-7f1a4000     Deferred        libexpat.so.1
ELF     0x7f1a4000-7f1d3000     Deferred        libfontconfig.so.1
ELF     0x7f1d3000-7f23f000     Deferred        libfreetype.so.6
ELF     0x7f23f000-7f26e000     Deferred        winspool<elf>
  \-PE  0x7f250000-7f26e000     \               winspool
ELF     0x7f26e000-7f288000     Deferred        wsock32<elf>
  \-PE  0x7f270000-7f288000     \               wsock32
ELF     0x7f288000-7f2a8000     Deferred        mpr<elf>
  \-PE  0x7f290000-7f2a8000     \               mpr
ELF     0x7f2a8000-7f2f0000     Deferred        wininet<elf>
  \-PE  0x7f2b0000-7f2f0000     \               wininet
ELF     0x7f2f0000-7f310000     Deferred        cabinet<elf>
  \-PE  0x7f300000-7f310000     \               cabinet
ELF     0x7f310000-7f346000     Deferred        urlmon<elf>
  \-PE  0x7f320000-7f346000     \               urlmon
ELF     0x7f346000-7f3e1000     Deferred        oleaut32<elf>
  \-PE  0x7f360000-7f3e1000     \               oleaut32
ELF     0x7f3e1000-7f422000     Deferred        crypt32<elf>
  \-PE  0x7f3f0000-7f422000     \               crypt32
ELF     0x7f422000-7f44d000     Deferred        ws2_32<elf>
  \-PE  0x7f430000-7f44d000     \               ws2_32
ELF     0x7f44d000-7f4d6000     Deferred        winmm<elf>
  \-PE  0x7f460000-7f4d6000     \               winmm
ELF     0x7f4d6000-7f59c000     Deferred        comctl32<elf>
  \-PE  0x7f4e0000-7f59c000     \               comctl32
ELF     0x7f59c000-7f5bb000     Deferred        iphlpapi<elf>
  \-PE  0x7f5a0000-7f5bb000     \               iphlpapi
ELF     0x7f5bb000-7f607000     Deferred        rpcrt4<elf>
  \-PE  0x7f5d0000-7f607000     \               rpcrt4
ELF     0x7f607000-7f69d000     Deferred        ole32<elf>
  \-PE  0x7f620000-7f69d000     \               ole32
ELF     0x7f69d000-7f6fb000     Deferred        shlwapi<elf>
  \-PE  0x7f6b0000-7f6fb000     \               shlwapi
ELF     0x7f6fb000-7f7d2000     Deferred        shell32<elf>
  \-PE  0x7f710000-7f7d2000     \               shell32
ELF     0x7f7d2000-7f7dd000     Deferred        libgcc_s.so.1
ELF     0x7f7e0000-7f7f4000     Deferred        libz.so.1
ELF     0x7f8d5000-7f98b000     Deferred        gdi32<elf>
  \-PE  0x7f8f0000-7f98b000     \               gdi32
ELF     0x7f98b000-7fabe000     Deferred        user32<elf>
  \-PE  0x7f9b0000-7fabe000     \               user32
ELF     0x7fabe000-7fb00000     Deferred        advapi32<elf>
  \-PE  0x7fad0000-7fb00000     \               advapi32
ELF     0x7fc13000-7fc1c000     Deferred        libxcursor.so.1
ELF     0x7fc48000-7fd50000     Export          kernel32<elf>
  \-PE  0x7fc60000-7fd50000     \               kernel32
ELF     0x7fd52000-7fd60000     Deferred        libxext.so.6
ELF     0x7fe74000-7fe80000     Deferred        libnss_files.so.2
ELF     0x7fe80000-7fe8a000     Deferred        libnss_nis.so.2
ELF     0x7fe8a000-7fea0000     Deferred        libnsl.so.1
ELF     0x7fea0000-7fea9000     Deferred        libnss_compat.so.2
ELF     0x7fea9000-7fead000     Deferred        iso8859-15.so
ELF     0x7fead000-7feb0000     Deferred        xlcdef.so.2
ELF     0x7feb2000-7feb6000     Deferred        libxrandr.so.2
ELF     0x7feb6000-7febb000     Deferred        libxxf86vm.so.1
ELF     0x7febb000-7fec0000     Deferred        libxxf86dga.so.1
ELF     0x7fec4000-7feea000     Deferred        libm.so.6
ELF     0x7feea000-7ffe0000     Deferred        libwine_unicode.so.1
ELF     0xb7d92000-b7d96000     Deferred        libdl.so.2
ELF     0xb7d96000-b7ece000     Export          libc.so.6
ELF     0xb7ece000-b7ee1000     Export          libpthread.so.0
ELF     0xb7ee2000-b7ee4000     Deferred        libnvidia-tls.so.1
ELF     0xb7ef8000-b7f12000     Deferred        libwine.so.1
ELF     0xb7f14000-b7f2b000     Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
0000000c (D) C:\Program Files\eMule\emule.exe
        00000013   -1 <==
        0000000f    0
        0000000e    0
        0000000d    0
0000000a
        0000000b    0
00000008
        00000009    0

[fabtar]

I have done a mistake , I had version 9.12 ; I'm going to try out wine 9.15 , I think this is the solution ;-)

[fabtar]

fabtar, on Jul 14 2006, 10:16 PM, said:

I have done a mistake , I had version 9.12 ; I'm going to try out wine 9.15 , I think this is the solution ;-)

with 9.15 emule is perfectly working

[Casablanca]

The bug "3063 - emule exposes socket/file handle leak" is still a problem in Wine 0.9.17. In Crossover Office 5.0.1, it happens as well. I couldn't get it to run in WineX, but the same bug is described as happening to a game. eMule runs in Win4Lin, but horribly slowly and I could not get ports forwarded. VMWare should work, and VMWare Server/Player are free.

It also does not fix the bug to use native DLLs for wininet etc.

If you have a spare email address, hop on over to the Wine bugzilla, register, and vote for the bug-
http://bugs.winehq.o...bug.cgi?id=3063 . Add any useful information you can.

This post has been edited by Casablanca: 25 July 2006 - 05:58 AM

[mindpirate]

mindpirate, on Jun 20 2006, 12:57 PM, said:

pjv3, on Jun 18 2006, 01:23 AM, said:

I'll try to log something at winehq, however, I note that these problems with wine + emule have been listed here since 2004, so it doesn't look like a high priority.

Yeah, and you'll notice they still haven't bumped the severity of Wine Bug 3063 - emule exposes socket/file handle leak up to "critical" as requested (and a bug that repeatedly results in a crash is a critical bug). Seems the Wine devs aren't paying attention, so perhaps you should open a new bug for your issue and as justification it should mention that the older bug hasn't been marked "critical". This way if some Wine dev marks the new bug a dupe, at least they'll be forced to deal with updating the severity of the older bug.

Some days I really feel like throwing in the towel. More people have stepped forward on Wine Bugzilla to confirm Wine Bug 3036 and ask for it to be properly reclassified as "critical", but now we seem to have the Mussolini of Bugzilla stonewalling us:

Wine Bug 6506 - Poor bug severity classification practices

On another note, I've updated the HOWTO to retire that nasty scrollbox bug from Known Issues and add a new minor issue:

Wine Bug 5844 - tray minimize

[mindpirate]

Just added a useful tip regarding Wine Bug 3063 to the HOWTO's Known Issues section.

[mindpirate]

Great news finally. Alexandre Julliard has rewritten Wine's WS_select() code to fix the leaky handles. Please try the patch he posted on Wine Bug 3063 and report your results there.

[mindpirate]

They committed the patch to the tree and marked the bug FIXED, so as of the next release of Wine (0.9.25 most likely) the long-standing Wine Bug 3063 should be history. If anyone continues to have socket leak problems with the new code, please let them know on that bug report.

[Casablanca]

I saw it the same day you did, but you beat me by hours ;-). This is very good news. Linux has a much better networking implementation, and other technology such as ReiserFS and more extensive multithreading that'll make eMule perform much better. Without this bug, all thats left is some superficial graphical glitches. Perhaps it'll be possible to compile eMule against Winelib even to make it pseudo-linux-native.

I don't know the official WINE schedule, but the next update I would guess is an update sometime around Saturday.

Yuri reports the bug is still there when applying the patch to the non-CVS last release, so it may be best to wait until release (unless you have some spare bugtesting time and a spare machine) as patching CVS is often inadvisable on a production machine.

This post has been edited by Casablanca: 06 November 2006 - 10:22 PM

[mindpirate]

Updated HOWTO to revision 2.0:

• Since the notorious Wine bug 3063 was fixed in Wine 0.9.25 it has been removed from Known Issues. No more socket handle leaks or related crashes! Thanks to all who assisted in getting this issue recognized and fixed.
  
  
  
• Added a new Tips section for things that are especially helpful for eMule usage under Wine. Suggestions for new tips are welcome!

[hszFS]

Using totally updated Debian (with wine 0.9.25) emule.exe and wineserver still permanently use 40% CPU together and the Webinterface does not load completely. If you read this thread you will notice that I have described this problem months ago already. Notice that I am using debian testing to try it so it contains all fancy new updated packages.
WTF is this damn bug???

I've been planning to run eMule on my router for like one year now

This post has been edited by hszFS: 12 December 2006 - 04:07 PM

[mindpirate]

hszFS, on Dec 12 2006, 10:02 AM, said:

Using totally updated Debian (with wine 0.9.25) emule.exe and wineserver still permanently use 40% CPU together

You never mentioned what kind of CPU and how much RAM you have. Do you have a Pentium 2? Are you running low on RAM causing your system to swap like crazy?

Quote

and the Webinterface does not load completely.

I thought the recent socket code rewrite might have fixed this, but it's apparently a separate problem. Wine's HTTP lib perhaps. File a bug at http://bugs.winehq.org/.

Quote

Notice that I am using debian testing to try it so it contains all fancy new updated packages.

Notice also that the latest version of Wine is 0.9.27. (I doubt it will fix your issues though.)

[hszFS]

Quote

You never mentioned what kind of CPU and how much RAM you have. Do you have a Pentium 2? Are you running low on RAM causing your system to swap like crazy?

It's a pentium2 with 400MHz, the system has enough RAM. And notice that I am doing idle tests with a blank eMule config without any downloads or connections and it still uses CPU time like crazy. Besides this problem also occurs when I test it on my P4 2.8GHz main box in VMware ...

Quote

Notice also that the latest version of Wine is 0.9.27. (I doubt it will fix your issues though.)

... and in VMware I especially used Ubuntu so that I could test it with the latest wine package directly from winehq.com
I guess I will finally create a bug report at winehq this week. I didn't do that yet because I am quite annoyed by opensource bug reporting hehe.

This post has been edited by hszFS: 18 December 2006 - 12:23 AM

[mindpirate]

hszFS, on Dec 17 2006, 06:15 PM, said:

It's a pentium2 with 400MHz, the system has enough RAM. And notice that I am doing idle tests with a blank eMule config without any downloads or connections and it still uses CPU time like crazy.

There's part of your problem. Running anything under Wine, not just eMule, on a 400 MHz Pentium 2 is going to eat up significant CPU resources. If the wineserver process can typically use 5-10% of my 2.2 GHz Athlon, then your 40% is quite expected don't you think? That's not to say that Wine's runtime couldn't be better optimized however.

Quote

Besides this problem also occurs when I test it on my P4 2.8GHz main box in VMware ...

Sorry, I don't see what you mean here. Are you running eMule under Wine under Linux on VMWare? Or are you running eMule under Windows under VMWare? In the former case, that's a lot of translation layers even for a 2.8 GHz box. In the latter case, obviously any CPU hogging has absolutely nothing to do with Wine.

[hszFS]

Quote

There's part of your problem. Running anything under Wine, not just eMule, on a 400 MHz Pentium 2 is going to eat up significant CPU resources. If the wineserver process can typically use 5-10% of my 2.2 GHz Athlon, then your 40% is quite expected don't you think? That's not to say that Wine's runtime couldn't be better optimized however.

Well, first of all, any sane GUI software should not use any CPU when idle. It has to be in "waiting for events/signals/interrupts" state, i.e. all threads would be sleeping waiting for events such as network packets arriving or GUI interaction like mouseclicks. There is no reason for an infinite loop to take 40% CPU time.
OK, I don't know how wine is programmed. Maybe it has some loop which runs every 1/10 second.
But this still does not explain why the Webinterface does not serve the request in a finite time, I have waited for like one minute and the page does not load completely. If it was a CPU-usage problem then it should at least finish after a certain time.

Quote

Besides this problem also occurs when I test it on my P4 2.8GHz main box in VMware ...
Sorry, I don't see what you mean here. Are you running eMule under Wine under Linux on VMWare?

Yes. My main box is a windows machine, there I run VMWare and in VMWare I ran linux to test eMule on wine.
So even with the 2.8 GHz backend wineserver/eMule use CPU like crazy and the Webinterface does not load.

This post has been edited by hszFS: 18 December 2006 - 06:01 PM

[mindpirate]

hszFS, on Dec 18 2006, 12:00 PM, said:

Well, first of all, any sane GUI software should not use any CPU when idle. It has to be in "waiting for events/signals/interrupts" state, i.e. all threads would be sleeping waiting for events such as network packets arriving or GUI interaction like mouseclicks. There is no reason for an infinite loop to take 40% CPU time.
OK, I don't know how wine is programmed. Maybe it has some loop which runs every 1/10 second.

Yep, all it takes is one event loop running too tightly.

Quote

But this still does not explain why the Webinterface does not serve the request in a finite time, I have waited for like one minute and the page does not load completely. If it was a CPU-usage problem then it should at least finish after a certain time.

The web interface problem may be separate from the CPU usage problem.

I've analyzed the web interface traffic using Wireshark and the HTTP session is textbook and error-free when accessed by a browser running on localhost. But when the web interface is accessed from a browser elsewhere on the LAN the packets for the session arrive seriously out-of-order and mangled, causing the session to stall indefinitely. I'm still not sure why it should act differently over the localhost interface than it does over the LAN interface.

[hszFS]

Quote

Yep, all it takes is one event loop running too tightly.

Well, I've tested it in VMware again. 70% cpu usage.
I have created a bug report with an attached Wine logfile now:
http://bugs.winehq.o...bug.cgi?id=6936

Quote

I've analyzed the web interface traffic using Wireshark and the HTTP session is textbook and error-free when accessed by a browser running on localhost. But when the web interface is accessed from a browser elsewhere on the LAN the packets for the session arrive seriously out-of-order and mangled, causing the session to stall indefinitely. I'm still not sure why it should act differently over the localhost interface than it does over the LAN interface.

Hmmz. Well with previous Wine versions the CPU usage was always at 100%, not it's only 70%.
Back then I thought that the one thread doing the infinite loop was taking all CPU-time from the network thread.
But now this is not clear, yes.

Maybe you can precisely specify the results of your network tests in my bugreport at winehq?

This post has been edited by hszFS: 18 December 2006 - 07:11 PM

[hszFS]

Well some guy urged me to create a separate bug report for the Webinterface problem.
Mindpirate could you do that in a detailled way? You could provide your traffic analysis.
I will confirm the problem then.

You know I'm kind of sick of my main computer running in my sleeping room all year long, it's enough now
I wanna finally start running eMule on my router so that I don't hear computers at night anymore.
And the Webinterface problem crap is the only thing which prevents me from doing that actually
Let's hope that the Wine developers pay attention to the problem...

This post has been edited by hszFS: 19 December 2006 - 11:41 PM