aMule Forum
English => Compilation problems => Topic started by: Radek on January 22, 2006, 12:33:51 PM
-
When trying a "make check" with today's snapshot I get the following
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I./.. -I../../src -I../../src/libs -I/mingw/lib/wx/include/msw-unicode-release-static-2.7 -I/mingw/include/wx-2.7 -D__WXMSW__ -mthreads -DwxUSE_GUI=0 -DMULEUNIT -DNOMINMAX -DUSE_EMBEDDED_CRYPTO -W -Wall -Wshadow -Wundef -g -ggdb -fno-inline -D__DEBUG__ -fmessage-length=0 -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -MT FileDataIOTest-FileDataIOTest.o -MD -MP -MF ".deps/FileDataIOTest-FileDataIOTest.Tpo" -c -o FileDataIOTest-FileDataIOTest.o `test -f 'FileDataIOTest.cpp' || echo './'`FileDataIOTest.cpp; \
then mv -f ".deps/FileDataIOTest-FileDataIOTest.Tpo" ".deps/FileDataIOTest-FileDataIOTest.Po"; else rm -f ".deps/FileDataIOTest-FileDataIOTest.Tpo"; exit 1; fi
In file included from ../../src/CFile.h:29,
from FileDataIOTest.cpp:2:
../../src/SafeFile.h:204:2: warning: #warning DOCS
FileDataIOTest.cpp: In member function `virtual void CMemFileAttachedBufferTest::run()':
FileDataIOTest.cpp:648: error: call of overloaded `CMemFile(NULL, int)' is ambiguous
../../src/MemFile.h:93: note: candidates are: CMemFile::CMemFile(const uint8_t*, size_t)
../../src/MemFile.h:92: note: CMemFile::CMemFile(uint8_t*, size_t)
make[3]: *** [FileDataIOTest-FileDataIOTest.o] Error 1
-
Hah. My changes PWNED Xaignar.
-
It's Kry's fault!
-
No it isn't!
-
With today's snapshot I get the following
Running test-collection "RangeMap" with 42 test-cases:
Test "DefaultConstructor"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 85 in RangeMapTest.cpp
Test "CopyConstructor"
FAIL: RangeMapTestThis was after I had received a popup from RangeMapTest.exe with the message, that an instruction at 0x004b263e would try to read from memory location 0x00000008, which was not possible.
================================
1 of 5 tests failed
Please report to [EMAIL]admin@amule.org[/EMAIL]
================================
-
haha!
-
Please test tomorrows snapshot, or apply this patch and tell me what happens. It seems to me that something rather strange is going on there.
-
No difference with today's snapshot (20060126) ?!
For the records: gcc 3.4.5, MingW, wxCVS, WinXP.
And this time I made an extra start of RangeMapTest.exe with gdb#0 0x004b25d6 in std::_Rb_tree >, std::_Select1st > >, std::less, std::allocator > > >::_M_root() const (this=0x0)
at e:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_tree.h:442
#1 0x004b3968 in std::_Rb_tree >, std::_Select1st > >, std::less, std::allocator > > >::_Rb_tree(std::_Rb_tree >, std::_Select1st > >, std::less, std::allocator > > > const&) (this=0x22fc10, __x=@0x0)
at e:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_tree.h:557
#2 0x004982a0 in __gnu_norm::map, std::less, std::allocator > > >::map(__gnu_norm::map, std::less, std::allocator > > > const&) (this=0x22fc10, __x=@0x0)
at e:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_map.h:166
#3 0x0049f4e8 in __gnu_debug_def::map, std::less, std::allocator > > >::map(__gnu_debug_def::map, std::less, std::allocator > > > const&) (this=0x22fc10,
__x=@0x0)
at e:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/debug/map.h:86
#4 0x004acee0 in CRangeMap::CRangeMap(CRangeMap const&) (this=0x22fc10, other=@0x0)
at ../../src/RangeMap.h:239
#5 0x004017fc in RangeMapCopyConstructorTest::run() (this=0x4cf070)
at RangeMapTest.cpp:186
#6 0x0048bd8f in muleunit::TestCase::run() (this=0x3d63d0) at testcase.cpp:111
#7 0x0048b69a in muleunit::TestRegistry::runTests() (this=0x4d66c0)
at testregistry.cpp:81
#8 0x0048b329 in muleunit::TestRegistry::runAndPrint() ()
at testregistry.cpp:52
#9 0x00498ee3 in UnitTestApp::OnRun() (this=0x3d8fa0) at main.cpp:36
#10 0x0047cdd7 in wxEntryReal(int&, wchar_t**) ()
#11 0x00489ad0 in main (argc=1, argv=0x3d2d98) at main.cpp:283
(gdb) cont
Continuing.
Program exited with code 030000000005.
-
Radek,
could you try inserting the following snipped in unittests/tests/RangeMapTest.cpp:
Old:
TEST(RangeMap, DefaultConstructor)
{
TestRangeMap map;
[snip]
New:
TEST(RangeMap, DefaultConstructor)
{
uint64 foo = 100, bar = 150;
int* baz = (int*)1;
wxString teststr = wxString::Format(wxT("%llu %llu %li), foo, bar, baz);
TestRangeMap map;
[snip]
And tell me the output of running the test.
EDIT: Also, if possible, can you join #amule? Since that would speed up this exchange a bit. ;)
-
Uh. OK, I made the suggestion to Xaignar that he make this suggestion to you, but apparently I wasn't clear. Or Xaignar was sleepy.
The new code should be:
TEST(RangeMap, DefaultConstructor)
{
uint64 foo = 100, bar = 150;
int* baz = (int*)1;
wxString teststr = wxString::Format(wxT("%llu %llu %li"), foo, bar, baz);
ASSERT_EQUALS(wxT("100 150 1"), teststr);
TestRangeMap map;
[snip]
The difference being: 1) corrected a missing quote character, and 2) actually test the value of teststr. ;)
-
I ran "make check" with the patch above. This is the output
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Running test-collection "RangeMap" with 42 test-cases:
Test "DefaultConstructor"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Failure: "Expected '100 150 1' but got '100 0 150'" line 178 in RangeMapTest.cpp
Test "CopyConstructor"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Test "AssignmentOperator"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Test "Equality"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Failure: "mapA == mapB" line 238 in RangeMapTest.cpp
Test "Iterators"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Failure: "Expected '(100, 124, 0)' but got '(125, 0, 175)'" line 260 in RangeMapTest.cpp
Test "Erase"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Failure: "Expected '[(100, 124, 0), (125, 175, 2), (176, 200, 1)]' but got '[(125, 0, 175)]'" line 290 in RangeMapTest.cpp
Test "Clear"
Failure: "Expected '[(100, 150, 0)]' but got '[(100, 0, 150)]'" line 91 in RangeMapTest.cpp
Test "FindRange"
e:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/debug/safe_iterator.h:193:
error: attempt to dereference a past-the-end iterator.
Objects involved in the operation:
iterator "this" @ 0x0022FBE0 {
type = N11__gnu_debug14_Safe_iteratorISt17_Rb_tree_iteratorISt4pairIKy15CRangeMapHelperIPiyEEEN15__gnu_debug_def3mapIyS6_St4lessIyESaIS7_EEEEE (mutable iterator);
state = past-the-end;
references sequence with type `N15__gnu_debug_def3mapIy15CRangeMapHelperIPiyESt4lessIyESaISt4pairIKyS3_EEEE' @ 0x0022FBE0
}
FAIL: RangeMapTestNo popup anymore.
-
Failure: "Expected '100 150 1' but got '100 0 150'" line 178 in RangeMapTest.cpp
This confirms that the problem is not due to any aMule code. It's an interaction between wxString::Format, the compiler, and the C runtime library. It apparently doesn't cope properly with 64-bit arguments to vararg functions. Or, the particular variant of printf which is used inside of wxString::Format doesn't cope well with "%llu" format specifiers. Or, it's a weird hack that wxString::Format does: it copies a va_list data structure, which seems to be an unsupported operation and might not be working properly.
-
@ken
In the meantime we made some experiments and found out, that it was indeed a problem with the format specifier "%llu". It was not interpreted as 64bit, so the argument was taken as 32bit, the next argument from lower half of the first argument and so on :(
When compiling under MingW/Win32, the format specifiers of some M$-DLL have to be used, because the call of *printf finally goes there. For these DLLs the correct specifier would be "%I64u", which I personally consider very ugly (the typical "special" way of M$).
There is a workaround (a DEFINE in defs.h) for this, which is used now in the test suite.
Starting with yesterday's snapshot, the problem is solved. I just forgot to change the thread title...