Compile MCServer on Mac OS?
#11
I'll try compiling again with a plain rev. 445 source code cos that sounds really weird.

As to the cSocketThread, I have no idea - I cant write code (except quick and dirty shell scripts Smile )

So, what should I do to try and find the problem?
Reply
Thanks given by:
#12
Can you provide a bit more info on the hardware and OS used? I don't have much experience with latest Macs, but I seem to remember they switched from big-endian (motorola) to little-endian (intel) chips and that the OS is very picky about some API calls.
For example here: http://seclists.org/nmap-dev/2008/q3/172 they report a similar issue, but we are already using what they're describing as the fix.

I'll try one more thing that came to my mind - sockaddr_in may have other members which are left unitialized in current MCServer code, so I'll try initializing them to all zeroes first. It might just fix the bind() problem.
Reply
Thanks given by:
#13
I'm running a 2009 MacBook with a 2.26 GHz Intel Core 2 Duo processor. Mac OS X 10.6.8 (Darwin 10.8.0)
I have Xcode 3.2.6 which comes with gcc i686-apple-darwin10-gcc-4.2.1 and GNU Make 3.81.

I checked again and rev 447 trunk gives crazy world errors, but zlib_fail_debugging does not. weird.

Maybe we should try taking the zlib_fail_debugging source code, and gradually change it back into the trunk source code and see at what point it conks out, and that would tell us what the zlib_fail_debugging source code is doing to make it work.
Reply
Thanks given by:
#14
I added some conversions that happen in the uncompress() call to the zlib_fail branch, can you try the branch at rev 449 and see if it fails?

Also, both trunk and the branch now have in them the attempt for the bind() fix, can you verify on either that it works? (should be no more cSocketThreads errors in the log)
Reply
Thanks given by:
#15
The branch works perfectly, but the trunk still has the crash and the decompression errors.
Reply
Thanks given by:
#16
Can you compile the mini program at http://xoft.cz/mcb/zlib_sizes.cpp and run it? It should print out two sizes, if they are different from each other, then we've probably nailed down the bug.

Also, I committed a possible fix as rev 452 to the trunk, so give it a try, too.
Reply
Thanks given by:
#17
It seems the last fix (rev 452) was the final nail into the error's coffin, it started working for Hunterz on his server, so I suppose it will work on yours, too.
Reply
Thanks given by:
#18
I was wondering, there's been long silence. Does the server work for you now, or are there still decompression errors?
If it works, can you put "[fixed]" in front of the thread title? Thanks.
Reply
Thanks given by:
#19
Sorry for the slow reply, I was on holiday and was unable to steal any wifiTongue

The decompression errors in trunk are fixed, but I still get that darn crash when I try to log in Sad

Code:
[27b7000|10:37:58] Client "127.0.0.1" connected!
[27b7000|10:37:58] New ClientHandle created at 0x101001400
[27b7000|10:37:58] Creating a new cSocketThread (currently have 0)
[27b7000|10:37:58] Error on shutting down socket ()
[1a0a000|10:37:58] Error on shutting down socket (127.0.0.1)
Segmentation fault
Reply
Thanks given by:
#20
Well, at least one error fixed Smile
From the log it seems something that I considered never-faulting actually faults, and there's no log about it, just the subsequent errors. I'll need to put more error-logging into SocketThreads to find this one.
Reply
Thanks given by:




Users browsing this thread: 9 Guest(s)