Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 223. (Read 5805531 times)

It certainly would not hurt to try. I have yet to upload debug builds of 3.4.3 and will do so later today, but the underlying stratum code has not changed since 3.4.2, it just had added features rather than changing the codebase.

So... would it be useful to run w/o a backup pool to see if the problem persists?  FYI I've only had it happen once.  But I regularly only let it run 24 hours before I restart it for one reason or another.  Until recently.  I'm remote from my miners for a bit ... from the looks of things my erupters ran for about 3 days before crashing.  I'm hoping my wife can restart it, but it's asking too much to get a screenshot of the error.  Last time I had the crash it was after 36 hours.  And my machine with only 2 erupters is still running.

M

All writes are done from one thread. All reads are done from one thread. Therefore there is no chance of there being a race on reads or a race on writes. I very much doubt windows has an issue of writing and reading the same socket at the same time, nor would there be a problem using two different sockets at the same time. Debugging points to something in socket code, possibly on reconnecting or trying to communicate with a backup pool. I keep auditing the code and come up none the wiser, but I will continue to do so, or give up entirely and stop supporting windows (yeah right, 85% of cgminer users are on windows sigh).

I'm not sure of the threading level within stratum when on a single pool.
ckolivas will know the answer to that.

Firefox is under continual development as well.  socket coding isn't simple, especially windows socket coding.  I personally have not seen any app crashes with firefox, and that's all I use.  if it is indeed a problem with winsock, for microsoft to address it you'll need to be able to provide poc code that causes the crash. 

Kano: would it help if I changed my cgminer instance to not have any backup pools?  then it's only communicating with one pool. 

M

... of course there are other possibilities as I came across with libusb ...

I am doing something with libusb that ... it would appear ... no one else on the planet does?

Running a multi-threaded application to many devices through the libusb library that states it is thread safe.
However, it is not thread safe.
I found that the comments on the libusb site that stated it was thread safe in fact suggested to me that it wasn't.
One of the libusb fixes was indeed to make libusb calls thread safe in cgminer using locks.

So ... a mining application that is talking to many pools at once through a single dll that "May" be thread safe, might actually NOT be thread safe and since it may be indeed rare for applications to do this on their own, it may be that cgminer is the rare case finding the problem ...

Of course it MAY not be - but certainly no proof to discount it at this stage.

Edit: of course I am replying to this also:

Yes a lot use the winsock dll. Note the issue is in mswsock.dll though, and it is actually very rare that applications use raw sockets on windows so I wouldn't say it's quite the same - firefox only recently started using it and lo and behold it's been getting crashes in the same library. Nonetheless, logically my code which is always in heavy development is far more likely to be at fault than an OS provided library (though we've been burnt by that enough already to know it's not impossible). Every attempt so far to get debugging with a full debug build, it always ends up crashing with an overflow in mswsock.dll though, so not sure where to go next...

I hate to be the bearer of bad news, but I doubt it's the winsock dll.  A lot of programs use that, and if there was a native problem in there, we'd be getting crashes elsewhere from other apps.

Since you code in linux for linux, and port to Windows, what's doing the conversion of your code to what windows uses?  From my experience, problems that make themselves apparent after a period of time indicate a memory leak (a), a multithreaded issue (b), or an unmanaged code issue (c). 

(a) should be apparent by increased memory usage or your internal memory leak testing (which I think I've seen you guys say you have)
(b) is awful to troubleshoot.  such problems are caused by different multithreading problems like race conditions or deadly embraces
(c) is generally code accessing memory regions that it shouldn't be accessing, like exceeding an array boundary

(b) and (c) are particularly troublesome because the problem may not always cause a symptom and the OS might not always detect it and clamp down on the offending app

third party code analyzers are the best way to spot these for complex code.  But if there are third party libraries involved, I doubt the code analyzers would be able to detect such things.

somehow I doubt I'm telling you anything you don't already know though.

M

Hmm. Thing is, the stratum code is all done raw now, not using any other libraries precisely because I had problems with libcurl and friends. So the code does raw socket calls which directly use winsock calls. So the problem is either in cgminer or the MS dll.

I've been using windows and troubleshooting windows problems long enough to know that the DLL that "crashed" is regularly not the DLL with the problem.  I think the error reporting mechanism from windows is flawed (imagine that), and it's a routine that's calling winsock that is the problem, not winsock.  Thinking through it, a possible example would be a multithreaded app crashing while one thread is in winsock.  Or it could be winsock crashing when trying to perform a requested call back to the owning app.

I've also seen this type of misleading error message when DLL #1 needs DLL #2.  The error message will state DLL #1 isn't found, and when you look, you'll see DLL #1 is there.  The reality is DLL #1 is looking for DLL #2 and not finding it, but the error message only captures part of the info is gives misleading info.

Overall, I don't believe this is a mswinsock issue.  It's probably not a cgminer issue either, per se, but one of the 3rd party DLLs you are using that is calling mswinsock.

M

He appears to be solo mining so there really isnt "accepted" shares.  When he finds a block, his accepted shares are of that of how many coins were in that block.

I didn't build from GIT.  I just grabbed the compiled off of http://ck.kolivas.org/apps/cgminer/
I did see your problem and solution a few pages back. Thanks for responding.

Just compiled the 3.4.3 this morning. To see if my USB issues with Eruptors where fixed.
I Was very pleased to see everything working without errors at max speed.

But i seem to have te same problem on my Raspberry Pi with Deb Weezy.
It crasheds at random , but Always around 25 minutes or so.

No bad SD, faulty hardware or so. I have three Pi's and all three have the same issue when using cgminer 3.4.3 and bfgminer runs like a charm.
I now, keep using that, but i like cgminer more, stopt using it when the libusb issue came on and i wan't it back

Thank you Kano. It's clear now, it was my bad that I assumed something wrong based on previous tests with a GPU and miss-interpretation of a short look of the api.c - File.

Since you've got comments not open on gitHub, I ask here if you notice this . Can in one of the next revisions you have multiple pools set to show thier own best share and accepted list somewhere. Maybe another option button from the selection above mining. I've got my mining set to rotate since eclipseMC is my default and its finding so many block that alot are not being counted and causing the numbers not to add up on the other.

If its just that my rotating is causing the bad numbers maybe a "stop accepting and finish" before rotating or other management strategies if that's not already how it works.

OP, pm me if this option kicks in or already exists.

I've got IPv6 unbound from the network adapter altogether.

Further to this discussion, I've seen quite a few bug reports quite recently about this same dll in combination with firefox. While I do believe the bug is in the dll itself, I wonder if there's a common variable bringing it on? Are those who are having problems with the dll using IPV6 by any chance?

Not that I think the cgminer devs should in any way be responsible for taking this action, but it is possible to open a ticket with Microsoft.  I don't believe per incident support is actually as expensive as one would expect, and I think the fee is refunded when a problem is proved to be a problem in their OS.  Getting high enough up the chain on the ticket might be tricky and might require reproducing the issue over and over again, so it could be easier for a dev, but I just thought I'd point out that it's more of an option than anyone might realize.  However, I don't use cgminer with Windows (I don't even have Win7 at home), so I can't really offer to help beyond the suggestion in this case, so this is just information for those more vested (either because they are effected or because someone offers them a donation for taking action).

Not totally a solution, but zero the stats would be easier than restarting.