Posts by Bob Benson

1) Message boards : News : N-Body 1.36 (Message 59860) Posted 9 Sep 2013 by Bob Benson Post: If you run Dependency Walker against the main N-Body executable, it will tell you which DLLs are linked and whether they are present on your computer. It will probably flag up libgomp_64-1.dll and pthreadGC2_64.dll (because the distribution names are different), and you usually get warnings about late-loading dependencies too - they can be ignored. But it helps to narrow the list of suspects down. Finally had time to look at this again. libgomp_64-1.dll and pthreadGC2_64.dll did indeed show as unresolved. So I copied libgomp_64-1_nbody_1.36.dll to just libgomp_64-1.dll, and similarly for pthread. I reactivated nbody on the machine, pulled some down. Runs like a champ on both the MT and non-MT versions. Resolves the issue on this machine. Hope it provides some help to others Bob
2) Message boards : News : N-Body 1.36 (Message 59693) Posted 27 Aug 2013 by Bob Benson Post: Most of those will be standard Windows system DLLs. Indeed, but disproves the stated "self-contained binaries" premise. Sorry, I come from The Old Days where "self contained" meant, well, everything's there, no exceptions or external dependencies, save the external base OS, which dlls really aren't, since there can be multiple different versions, as on my machine Walker appears to be a tool I've been looking for off and on. Thanks. Past number of years I've been breaking systems (white hat) more than building them, which is more networks and people than code. Bob
3) Message boards : News : N-Body 1.36 (Message 59680) Posted 26 Aug 2013 by Bob Benson Post: The binaries should be compiled completely self contained except for the two dlls that are distributed with the application. But of the reports of this we have been seeing they have all been Windows 7 machines. We test against Windows 7. Gave me something to look at. Here's what I saw, hope it helps - First, the other milkyway projects have a pretty long list of dlls they use - at least as reported by Process Explorer. Such as advapi32, KernalBase, lpk, ntdll, sechost, many more. The n-body craters so fast I haven't been able to catch it - perhaps if you run it in a debugger Second, the pthread.my.dll (I won't type that long name cuz I'd mistype it) has a different name from other pthread dlls installed on the machine. As it should if you've done something to it. None of those other dlls are loaded, or should be loaded, when n-body craters. I can't verify which pthread is actually being loaded, or if it even gets that far Third, when I examine the interfaces exported from pthread.my.dll, the names match those in other pthread dlls, the dll address and relative address don't (expected, different versions). All the pthreads on the machine show Relative Address of the form 0x000010c3, which looks relative. All pthreads on the machine EXCEPT pthreads.my export an Address in the same form, while the pthreads.my exports addrs like 0x672c1ae0, which looks absolute to me and could cause an out of addr space error if interpreted as relative (what we called 0C4 errors back in the mainframe days) And fourth, the error code is frequently linked to .Net 3.5. This machine came only with .Net 4. Matches a couple other Win7 machines I looked at, but they're not involved in any @home activity Hope this helps tracking down the problem Bob
4) Message boards : News : N-Body 1.36 (Message 59665) Posted 25 Aug 2013 by Bob Benson Post: <core_client_version>7.0.64</core_client_version> <![CDATA[ <message> (unknown error) - exit code -1073741515 (0xc0000135) </message> ]]> All (100%) of the n-body WUs have errored out this way on a machine I added in mid-June - machine id 523191, Win7 x64 Sp1. The only references to this error msg I've found to date all talk about a missing or bad piece of microsoft's .net 3.x package, which appears to be OK on the machine. So I've just been watching them crash, crunching the rest of the WUs, and checking back here from time to time Bob