Print

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

[wires]

I've found this links that may be useful
64-BIT PROGRAMMING MODELS about Unix standards
AMD64 and LP64 for me the important note here is that Linux is LP64 (instead of ILP64) on AMD64.

Which version did you use? You can't apply the revert-patch to 2.2.2 since the change is only in 2.2.3 and SVN.

You're right I've applied the patch to nothing, original idea was to apply it to latest SVN version just to see its behaviour, but finally I decided to start from zero with 2.2.2

The assemblers and command lines are attached. Please carefully review the compilation commands for errors, I've been failing with builds and other things and I don't want to be the one that made you read assembler for pleasure 


The only language where you can do high quality development work without understanding the intricate details of the compiler is "english", as used by a manager when telling the coders what to do. (Well, perhaps...)
ftp://

[Stu Redman]

Thank you very much for your effort! But the assembler is hard to chew. And I didn't even find that SetMessageBlink function. 

But I noticed something interesting:
amuleDlg is compiled with the app and with -pthread
ChatWnd is compiled with libmuleappgui and without -pthread
Doku says about -pthread:

Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags.

Now, where does this flag come from, and might it influence something?

[GonoszTopi]

Thank you very much for your effort! But the assembler is hard to chew. And I didn't even find that SetMessageBlink function. 

Because it's an inline function.

Now, where does this flag come from, and might it influence something?

Code: [Select]

$ grep -- -pthread Compilation.flags
LIBUPNP_CFLAGS = -pthread 
WXBASE_LIBS = -L/usr/local/lib -pthread   -lwx_baseud_2.8.9_net-2.8 -lwx_baseud_2.8.9-2.8
WX_CFLAGS = -I/usr/local/lib/wx/include/gtk2-unicode-debug-2.8-2.8.9 -I/usr/local/include/wx-2.8-2.8.9 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread
WX_CFLAGS_ONLY = -pthread
WX_CXXFLAGS = -I/usr/local/lib/wx/include/gtk2-unicode-debug-2.8-2.8.9 -I/usr/local/include/wx-2.8-2.8.9 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread
WX_LIBS = -L/usr/local/lib -pthread   -lwx_gtk2ud_2.8.9_adv-2.8 -lwx_gtk2ud_2.8.9_core-2.8 -lwx_baseud_2.8.9_net-2.8 -lwx_baseud_2.8.9-2.8
$


[Stu Redman]

Wires, please try the following:

- in src/Makefile find the line WX_CPPFLAGS =
- add the option -pthread
- rebuild (make clean; make), check if the fence still triggers

Strange option that. GCC doku lists it under "IA64 architecture specific" (also PPC and Sparc). So why is it defined and accepted in my Ubuntu 32 also ?!?

SetMessageBlink is defined as callable function in ChatWnd.s btw. That's not what I would expect of  "inline".

Am I understanding correctly that Ubuntu 64 is for AMD only? What about 64 bit Intel CPUs (like mine)?

[wuischke]

The architecture is called amd64, because AMD introduced this extension to the x86 instruction set. The extended instruction set has been licensed by Intel and is used in its x86 64 bit processors. Sometimes you'll find the name x86_64, too, that's the same thing.

IA32 is more or less synonymous to x86; IA64 on the other hand is something different, that's Intel's Itanium. (Mentioning Itanium: They killed Alpha! )

In short: amd64 works fine on 64 bit capable Intel (x86) processors. In my case, that's a mobile C2D.

[Stu Redman]

Ok, maybe I'll try to get it running in my VM (no idea if that's possible with a 32 bit host).
They have a dirty kind of humor btw - or is it just me ? 

[wires]

Strange option that. GCC doku lists it under "IA64 architecture specific" (also PPC and Sparc). So why is it defined and accepted in my Ubuntu 32 also ?!?

From man page (man 7 pthreads)

Compiling on Linux
       On Linux, programs that use the Pthreads API should be compiled using cc -pthread

SetMessageBlink is defined as callable function in ChatWnd.s btw. That's not what I would expect of  "inline".

One of the compilation flags is -fno-inline so `inline' keyword is ignored.

[GonoszTopi]

I think I found the source of the bug. Or at least I found a bug. And it has nothing to do with -pthreads.

wires, could you please try the following patch?

Code: [Select]

diff --git a/src/Makefile.am b/src/Makefile.am
index be7eda7..3499267 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -110,7 +110,7 @@ libmuleappgui_a_SOURCES = \
        MuleCollection.cpp \
        muuli_wdr.cpp
 
-libmuleappgui_a_CPPFLAGS = $(AM_CPPFLAGS) $(WX_CPPFLAGS) -I$(srcdir)/libs -I$(srcdir)/include $(LIBUPNP_CPPFLAGS)
+libmuleappgui_a_CPPFLAGS = $(AM_CPPFLAGS) $(WX_CPPFLAGS) -I$(srcdir)/libs -I$(srcdir)/include $(LIBUPNP_CPPFLAGS) $(GEOIP_CPPFLAGS)
 
 core_sources = \
        RC4Encrypt.cpp \

Please re-run autogen.sh and configure, delete at least libmuleappgui.a (or 'make clean'), and rebuild amule.

[wires]

Ok! it's done! And the winner is GonoszTopi  !!! I've tried the FLAGS patch from Stu and it didn't work, but the last patch from GonoszTopi actually works!! The message is received, the icon blinks and fences stay clear. I would like to know what's the cause, how can these compilation flags beak the runtime in such a way  . Here you are the log for a successful chat sesssion:

Code: [Select]

2009-03-04 09:32:20: ClientTCPSocket.cpp(336): Remote Client Protocol: Remote Client: OP_HELLO from 192.168.1.33
2009-03-04 09:32:20: BaseClient.cpp(985): Local Client Protocol: Local Client: OP_HELLOANSWER to 192.168.1.33
2009-03-04 09:32:20: BaseClient.cpp(799): Local Client Protocol: Local Client: OP_EMULEINFO/OS_INFO to 192.168.1.33
2009-03-04 09:32:20: BaseClient.cpp(2173): Local Client Protocol: Local Client: OP_SECIDENTSTATE to 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(2005): Remote Client Protocol: Packet with protocol c5, opcode 87, size 5 received from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(1346): Remote Client Protocol: Remote Client: OP_SECIDENTSTATE from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(2005): Remote Client Protocol: Packet with protocol e3, opcode 4e, size 8 received from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(795): Remote Client Protocol: Remote Client: OP_MESSAGE from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(805): New message from 'wires' (IP:192.168.1.33)
2009-03-04 09:32:20: ClientTCPSocket.cpp(2005): Remote Client Protocol: Packet with protocol c5, opcode 1, size 17 received from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(1326): Remote Client Protocol: Remote Client: OP_EMULEINFO is an OS_INFO
2009-03-04 09:32:20: ClientTCPSocket.cpp(2005): Remote Client Protocol: Packet with protocol c5, opcode 85, size 77 received from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(1371): Remote Client Protocol: Remote Client: OP_PUBLICKEY from 192.168.1.33
2009-03-04 09:32:20: BaseClient.cpp(2067): Local Client Protocol: Local Client: OP_SIGNATURE to 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(2005): Remote Client Protocol: Packet with protocol c5, opcode 86, size 49 received from 192.168.1.33
2009-03-04 09:32:20: ClientTCPSocket.cpp(1387): Remote Client Protocol: Remote Client: OP_SIGNATURE from 192.168.1.33
2009-03-04 09:32:20: BaseClient.cpp(2140): ED2k Client: 'wires' has passed the secure identification, V2 State: 0
2009-03-04 09:33:00: BaseClient.cpp(1321): ED2k Client: --- Deleted client "Client wires on IP:Port 192.168.1.33:14662 using aMule SVN v2.3.0 aMule SVN"; Reason was Timeout

These are the steps I've followed to rebuild amule:
1. rm -rf build
2. cd ../src
3. apply GonoszTopi patch to Makefile.am (manually add GEOIP_CPPFLAGS to libmuleappgui_a_CPPFLAGS)
4. cd ..
6. ./autogen.sh
5. mkdir build
6. cd build
7. $ ../configure --prefix=/home/xxxxx/aMule-SVN --enable-dependency-tracking --disable-upnp --enable-geoip --with-wxdebug --disable-optimize --enable-debug --disable-wxcas --disable-alc --disable-alcc --with-wx-debug --with-wx-config=/home/xxxx/wxGTK/bin/wx-config --with-wx=/home/xxxxx/wxGTK
8. make
9. make install

Thank you all for your time. Let me know if you need me to run more tests ok?

This is a bit off topic but during make I've found this:

Code: [Select]

$ make
Parsing 2 files
FileName: ECTagTypes
FileContent: EC tag types for use on the ec library.
Reading content section...
Datatype: Enum
Dataname: ECTagTypes
DataType: uint8
No more content sections
All info parsed
FileName: ECCodes
FileContent: EC codes and type definition.
Reading content section...
Datatype: TypeDef
Reading content section...
Datatype: Enum
Dataname: ProtocolVersion
DataType: uint16
Reading content section...
Datatype: Enum
Dataname: ECFlags
DataType: uint32
Reading content section...
Datatype: Enum
Dataname: ECOpCodes
DataType: uint8
Reading content section...
Datatype: Enum
Dataname: ECTagNames
DataType: uint16
Reading content section...
Datatype: Enum
Dataname: EC_DETAIL_LEVEL
DataType: uint8
Reading content section...
Datatype: Enum
Dataname: EC_SEARCH_TYPE
DataType: uint8
Reading content section...
Datatype: Enum
Dataname: EC_STATTREE_NODE_VALUE_TYPE
DataType: uint8
Reading content section...
Datatype: Enum
Dataname: EcPrefs
DataType: uint32
May be it is not important but enums are 32 bit in x86_64 so why it detects uint8/16/32 values? Feel free to quote this on a new post in the devel section ok? Not sure if that's the right way.

[wuischke]

Hi wires,

you are correct, enums are 32 bit. The output you see is related to the EC protocol. Basically a certain action is encoded by a number. When I send for instance 0x09, aMule knows I want to add a link. In the code we don't write 0x09 every time, but instead put all so called op codes in an enum. In ECCodes.h (src/libs/ec/cpp/) you'll find something like the following:

Code: [Select]

enum ECOpCodes {
...
EC_OP_ADD_LINK                      = 0x09,
...Everytime we use the enum value EC_OP_ADD_LINK in our code, it will be replaced by 0x09. But 0x09 is only 8 bit - it would waste a lot of bandwith if everytime we wanted to send a '9' we would use a 32 bit value. Therefore we convert the 32 bit value to a 8 bit value when sending it.

The output you see is used for the generation of the C++ code files from an abstract file in a perl script, which makes changing data types (maybe we'll have more than 255 op codes one day and need a uint16) and values easy.

[GonoszTopi]

I would like to know what's the cause, how can these compilation flags beak the runtime in such a way  .

First of all, Stu pointed out that somehow the bool value of m_BlinkMessages is written with a -8 bytes offset. Later in your compilation logs I discovered that amuleDlg.cpp was compiled with -DENABLE_IP2COUNTRY=1, but not ChatWnd.cpp. Then I was almost certain what the bug was, and soon found the following in amuleDlg.h:

Code: (amuleDlg.h) [Select]

#ifdef ENABLE_IP2COUNTRY
        CIP2Country*            m_IP2Country;
#endif

I was wondering why it affected only 64-bit, but it can either be related to data alignment done by the compiler, or something black magic.

[Stu Redman]

Ahhh - that's the bad thing about magic tricks. You're always so disappointed when you find out how it is done... 
Good to have that one nailed finally.

I was wondering why it affected only 64-bit, but it can either be related to data alignment done by the compiler, or something black magic.

Code: [Select]

CMuleTrayIcon *m_wndTaskbarNotifier;
DialogType m_nActiveDialog;
bool m_is_safe_state;
bool m_BlinkMessages;
With a displacement of 4 instead of 8 it only smashes the m_nActiveDialog and not the  m_wndTaskbarNotifier. I don't know the exact consequences of that - maybe only an extra dialog redraw or something, but no crash.

[wires]

Well, thank you for your explanations. I've enjoyed this chase! 

[btkaos]

First of all, Stu pointed out that somehow the bool value of m_BlinkMessages is written with a -8 bytes offset. Later in your compilation logs I discovered that amuleDlg.cpp was compiled with -DENABLE_IP2COUNTRY=1, but not ChatWnd.cpp. Then I was almost certain what the bug was, and soon found the following in amuleDlg.h:

Code: (amuleDlg.h) [Select]

#ifdef ENABLE_IP2COUNTRY
        CIP2Country*            m_IP2Country;
#endif


Impressive catch GonoszTopi!!

I was wondering why it affected only 64-bit, but it can either be related to data alignment done by the compiler, or something black magic.

[GonoszTopi]

Impressive catch GonoszTopi!!

You know, it isn't hard at all when others do the slave work