+1 for POST instead of GET.
Could you add an option [P]ause , so we could pause the current work, if we wanted to quickly use the gpu for another task, and then resume it later.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 828. (Read 5805677 times)
July 24, 2011, 06:00:46 AM
July 24, 2011, 04:26:55 AM
[2011-07-24 02:22:31] Failed to init GPU thread 0
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.
Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?
No funky values, but the truth
, so leave it like it is!Dia
July 24, 2011, 02:19:32 AM
re: POST vs GET on longpoll
I am absolutely getting sick of this freaking problem of how to do a longpoll. I originally converted to GET because someone suggested that's what the deepbit unofficial guide suggested was the way to do a longpoll. Then I discovered lots of other longpolls didn't work because MANY operating systems could easily lose their longpoll connection through routers and so on because they didn't issue any sort of keepalive for up to 2 hours by default (7200 seconds). So with help I converted it to use keepalives much more frequently. In the meantime, deepbit longpolls were BROKEN by the use of GET. Now someone posts me a fix for deepbit longpolls, using POST again. As far as I can see, there is NO ADVANTAGE to using GET and unless someone can positively prove me otherwise, I will be converting every longpoll to POST once more and putting this issue to bed forever.
I am absolutely getting sick of this freaking problem of how to do a longpoll. I originally converted to GET because someone suggested that's what the deepbit unofficial guide suggested was the way to do a longpoll. Then I discovered lots of other longpolls didn't work because MANY operating systems could easily lose their longpoll connection through routers and so on because they didn't issue any sort of keepalive for up to 2 hours by default (7200 seconds). So with help I converted it to use keepalives much more frequently. In the meantime, deepbit longpolls were BROKEN by the use of GET. Now someone posts me a fix for deepbit longpolls, using POST again. As far as I can see, there is NO ADVANTAGE to using GET and unless someone can positively prove me otherwise, I will be converting every longpoll to POST once more and putting this issue to bed forever.
July 23, 2011, 10:40:46 PM
Would it be possible to add a multipool strategy that's similar to load balance, but with the first one having priory? So the second one is just active when the first one for some reason doesn't have enough work, for example because of latency.
That's basically failover that you're describing... That's the default policy. Or do you mean micro delays instead of macro ones?
July 23, 2011, 10:40:15 PM
Not every work item has a solution. Thus you will not get always get the same number of submissions as queries. Conversely some work items have more than one solution. This leads to "efficiency" of greater than 100% (when not solo mining).
alright, i don't really get it, but it sounds like "it's not a bug". thanks for the answer!
As for the flag idea...
ya, it figures.
July 23, 2011, 10:34:25 PM
how does one specify phatk110714.cl or poclbm110717.cl ?
One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards.Phoenix with phatk worked on my 4850, and that was faster than poclbm.
July 23, 2011, 10:20:17 PM
when solo-mining, i get
what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".
another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<
Not every work item has a solution. Thus you will not get always get the same number of submissions as queries. Conversely some work items have more than one solution. This leads to "efficiency" of greater than 100% (when not solo mining).Code:
Q:1438 A:0 R:1360
what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".
another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<
As for the flag idea...
July 23, 2011, 09:29:27 PM
when solo-mining, i get
what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".
another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<
Code:
Q:1438 A:0 R:1360
what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".
another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<
July 23, 2011, 08:29:03 PM
ck, I am still trying to track down the annoying window resize segfault. I compiled the git version like this:
and started like this
Leave the -O2 -g on and try again (in gdb). Quote
CFLAGS="-O0 -g -Wall -march=native" ./configure --prefix=/opt/cgminer
and started like this
Quote
gdb /opt/cgminer/bin/cgminer
then I did "set args" and "run" and it does NOT segfault. If I run it like this from the command line it segfaults upon resize. Is there any other way to collect the information that would help you to fix the issue?
July 23, 2011, 08:24:43 PM
[2011-07-24 02:22:31] Failed to init GPU thread 0
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.
Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?
I was just coming back to say that it actually ramped back up to where it was was 1.3.1. I think it is fine as is now that I understand what to expect.
July 23, 2011, 08:22:21 PM
[2011-07-24 02:22:31] Failed to init GPU thread 0
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.
Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?
July 23, 2011, 08:19:52 PM
[2011-07-24 02:22:31] Failed to init GPU thread 0
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.
July 23, 2011, 08:00:36 PM
[2011-07-24 02:22:31] Failed to init GPU thread 0
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.
July 23, 2011, 07:25:45 PM
New trace on OSX (copied latest main.c and ocl.c to the 1.4.0 directory), same parameters as before + debug and verbose output:
I sincerely doubt the "idle for more than 60 seconds" message, especially since the program crashed before it ran that long.
Code:
[2011-07-24 02:22:31] Testing pool http://pit.deepbit.net:8332
[2011-07-24 02:22:31] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
[2011-07-24 02:22:31] Successfully retrieved and deciphered work from pool 0 http://pit.deepbit.net:8332
[2011-07-24 02:22:31] Pool 0 http://pit.deepbit.net:8332 active
[2011-07-24 02:22:31] Testing pool http://swepool.net:8337
[2011-07-24 02:22:31] X-Roll-Ntime found
[2011-07-24 02:22:31] Successfully retrieved and deciphered work from pool 1 http://swepool.net:8337
[2011-07-24 02:22:31] Pool 1 http://swepool.net:8337 active
[2011-07-24 02:22:31] Init GPU thread 0
[2011-07-24 02:22:31] List of devices:
[2011-07-24 02:22:31] 0 ATI Radeon HD 6750M
[2011-07-24 02:22:31] Selected 0: ATI Radeon HD 6750M
[2011-07-24 02:22:31] Preferred vector width reported 4
[2011-07-24 02:22:31] Max work group size reported 1024
[2011-07-24 02:22:31] Loaded binary image poclbm110717ATI Radeon HD 6750Mv2w128long8.bin
[2011-07-24 02:22:31] Initialising kernel poclbm110717.cl without BFI_INT patching, 2 vectors and worksize 128
[2011-07-24 02:22:31] Creating Command Queue. (clCreateCommandQueue)
[2011-07-24 02:22:31] Failed to init GPU thread 0
[2011-07-24 02:22:31] Init GPU thread 0
[2011-07-24 02:22:31] List of devices:
[2011-07-24 02:22:31] 0 ATI Radeon HD 6750M
[2011-07-24 02:22:31] Selected 0: ATI Radeon HD 6750M
[2011-07-24 02:22:31] Preferred vector width reported 4
[2011-07-24 02:22:31] Max work group size reported 1024
[2011-07-24 02:22:31] Loaded binary image poclbm110717ATI Radeon HD 6750Mv2w128long8.bin
[2011-07-24 02:22:31] Initialising kernel poclbm110717.cl without BFI_INT patching, 2 vectors and worksize 128
[2011-07-24 02:22:31] Creating Command Queue. (clCreateCommandQueue)
[2011-07-24 02:22:31] Failed to init GPU thread 0
[2011-07-24 02:22:31] 2 gpu miner threads started
[2011-07-24 02:22:31] 0 cpu miner threads started, using SHA256 'c' algorithm.
GPU 0: [0.0 Mh/s] [Q:0 A:0 R:0 HW:0 E:0% U:0.00/m]
[2011-07-24 02:22:33] Attempting to restart thread 0, idle for more than 60 seconds
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 559]
0x00000001000065aa in reinit_gputhread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2880
2880 if (!(pthread_cancel(*thr->pth)) && pthread_join(*thr->pth, NULL)) {
(gdb) backtrace
#0 0x00000001000065aa in reinit_gputhread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2880
#1 0x00000001000065aa in reinit_thread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2910
#2 0x00000001000065aa in watchdog_thread (userdata=) at main.c:3019
#3 0x00007fff81b74fd6 in _pthread_start ()
#4 0x00007fff81b74e89 in thread_start ()
July 23, 2011, 06:32:54 PM
Thanks! The backtrace helps to know why it segfaults (fixed in git now), but not why it's failing to create a command queue. I've tried backing out the compiler unloading patch as well in case that's the reason (changes are in git).
Great, thanks. I can't get ./autogen.sh to work (never have been able to get it to work on OS X) I think because OS X has the wrong version of autoconf (autoconf (GNU Autoconf) 2.61).
Hopefully ancow can test it, else I'll have to wait for the next source package that has ./configure already generated.
If you want to do it yourself, the only changes were to main.c and ocl.c, AFAICT, so simply copy those to the 1.4.0 directory and compile there (that's how I'm doing it).
July 23, 2011, 06:27:02 PM
ck, I am still trying to track down the annoying window resize segfault. I compiled the git version like this:
and started like this
Quote
CFLAGS="-O0 -g -Wall -march=native" ./configure --prefix=/opt/cgminer
and started like this
Quote
gdb /opt/cgminer/bin/cgminer
then I did "set args" and "run" and it does NOT segfault. If I run it like this from the command line it segfaults upon resize. Is there any other way to collect the information that would help you to fix the issue? July 23, 2011, 06:18:45 PM
Thanks! The backtrace helps to know why it segfaults (fixed in git now), but not why it's failing to create a command queue. I've tried backing out the compiler unloading patch as well in case that's the reason (changes are in git).
Great, thanks. I can't get ./autogen.sh to work (never have been able to get it to work on OS X) I think because OS X has the wrong version of autoconf (autoconf (GNU Autoconf) 2.61).
Hopefully ancow can test it, else I'll have to wait for the next source package that has ./configure already generated.
July 23, 2011, 06:14:47 PM
Some weirdness:
- If multiple, identical GPUs are present in the system, the same OpenCL kernel will be compiled for each of them.
No it does not. It compiles one kernel once for all similar hardware and then loads the binary from that point on. Since you have to run cgminer from the source directory currently, that's where it also stores the binary file.- If multiple, identical GPUs are present in the system, the same OpenCL kernel will be compiled for each of them.
So, I think I tracked down what led me to ask these questions.
My miner systems run without local disk and obtain everything over via PXE/TFTP/NFS. The directory where mining binaries (including cgminer) is installed isn't writable to the miner node users. Therefore, the binary output file can't be opened and, if I'm reading the source and the debug output correctly, the kernel is getting compiled memory-to-memory multiple times. Building to a temp directory would be one way to solve this.
In the process of troubleshooting, I found that adding the -T option to suppress curses output fails in a strange way with the latest linux binary. This works fine without -T, it's just hard to see everything that's going on as stuff scrolls up the curses window (and out of my scrollback):
Code:
box0202@box0202:/home/syadasti/software/cgminer-1.4.0$ ./cgminer --userpass user:pass --url http://pit.deepbit.net:8332 --debug -T
[2011-07-24 01:02:02] Testing pool http://pit.deepbit.net:8332
[2011-07-24 01:02:02] Successfully retrieved and deciphered work from pool 0 http://pit.deepbit.net:8332
[2011-07-24 01:02:02] Pool 0 http://pit.deepbit.net:8332 active
[2011-07-24 01:02:02] Init GPU thread 0
[2011-07-24 01:02:02] List of devices:
[2011-07-24 01:02:02] 0 Cypress
[2011-07-24 01:02:02] 1 Cypress
[2011-07-24 01:02:02] 2 Cypress
[2011-07-24 01:02:02] Selected 0: Cypress
[2011-07-24 01:02:02] Preferred vector width reported 4
[2011-07-24 01:02:02] Max work group size reported 256
[2011-07-24 01:02:02] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
[2011-07-24 01:02:02] No binary found, generating from source
[2011-07-24 01:02:02] Patched source to suit 2 vectors
[2011-07-24 01:02:02] cl_amd_media_ops found, patched source with BITALIGN
[2011-07-24 01:02:02] cl_amd_media_ops found, patched source with BFI_INT
*** glibc detected *** ./cgminer: free(): invalid next size (fast): 0x000000000125b4e0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7f6482a69606]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f6482a6e33c]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2f2a4e)[0x7f647e11ca4e]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2edd55)[0x7f647e117d55]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2ede4d)[0x7f647e117e4d]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x109ef6)[0x7f647df33ef6]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x138779)[0x7f647df62779]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x10a44c)[0x7f647df3444c]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x15716a)[0x7f647df8116a]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(clBuildProgram+0x2aa)[0x7f647df1277a]
./cgminer[0x40dbd6]
./cgminer[0x40af56]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f6482a15ead]
./cgminer[0x4030a9]
======= Memory map: ========
00400000-00437000 r-xp 00000000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00636000-00637000 r-xp 00036000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00637000-00638000 rwxp 00037000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00638000-00639000 rwxp 00000000 00:00 0
01237000-025ae000 rwxp 00000000 00:00 0 [heap]
7f6474000000-7f6474021000 rwxp 00000000 00:00 0
7f6474021000-7f6478000000 ---p 00000000 00:00 0
7f6478385000-7f6478592000 r-xp 00000000 00:1a 9551883 /opt/ati-stream-sdk-v2.3-lnx64/lib/gpu/builtins-gpucommon.bc
7f6478592000-7f64785c8000 r-xp 00000000 00:1a 9551881 /opt/ati-stream-sdk-v2.3-lnx64/lib/gpu/builtins-evergreen.bc
7f64785c8000-7f64785cd000 r-xp 00000000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64785cd000-7f64787cc000 ---p 00005000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787cc000-7f64787cd000 r-xp 00004000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787cd000-7f64787ce000 rwxp 00005000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787ce000-7f64787e3000 r-xp 00000000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64787e3000-7f64789e2000 ---p 00015000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e2000-7f64789e3000 r-xp 00014000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e3000-7f64789e4000 rwxp 00015000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e4000-7f64789e6000 rwxp 00000000 00:00 0
7f64789e6000-7f64789f0000 r-xp 00000000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f64789f0000-7f6478bef000 ---p 0000a000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bef000-7f6478bf0000 r-xp 00009000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bf0000-7f6478bf1000 rwxp 0000a000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bf1000-7f6478bfc000 r-xp 00000000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478bfc000-7f6478dfb000 ---p 0000b000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfb000-7f6478dfc000 r-xp 0000a000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfc000-7f6478dfd000 rwxp 0000b000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfd000-7f6478dfe000 ---p 00000000 00:00 0
7f6478dfe000-7f64795fe000 rwxp 00000000 00:00 0
7f64795fe000-7f64795ff000 ---p 00000000 00:00 0
7f64795ff000-7f6479dff000 rwxp 00000000 00:00 0
7f6479dff000-7f6479e00000 ---p 00000000 00:00 0
7f6479e00000-7f647a600000 rwxp 00000000 00:00 0
7f647a600000-7f647a602000 r-xp 00000000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a602000-7f647a801000 ---p 00002000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a801000-7f647a802000 rwxp 00001000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a802000-7f647a835000 r-xp 00000000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a835000-7f647a935000 ---p 00033000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a935000-7f647a93c000 rwxp 00033000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a94e000-7f647ad50000 rwxp 00000000 00:00 0
7f647ad50000-7f647ad51000 rwxs 22b79000 00:12 5350 /dev/ati/card2
7f647ad51000-7f647adb1000 rwxs 22b78000 00:12 5350 /dev/ati/card2
7f647adb1000-7f647adf1000 rwxs 00049000 00:12 5350 /dev/ati/card2
7f647adf1000-7f647b4f1000 rwxs 00026000 00:12 5350 /dev/ati/card2
7f647b4f1000-7f647b4f2000 rwxs 00025000 00:12 5350 /dev/ati/card2
7f647b4f2000-7f647b512000 rwxs febe0000 00:12 5350 /dev/ati/card2
7f647b512000-7f647b572000 rwxs 22b76000 00:12 5348 /dev/ati/card1
7f647b572000-7f647bc72000 rwxs 00016000 00:12 5348 /dev/ati/card1
7f647bc72000-7f647bcd2000 rwxs 22b74000 00:12 5337 /dev/ati/card0
7f647bcd2000-7f647bd12000 rwxs 00035000 00:12 5337 /dev/ati/card0
7f647bd12000-7f647c412000 rwxs 00006000 00:12 5337 /dev/ati/card0
7f647c412000-7f647c492000 rwxp 00000000 00:00 0
7f647c492000-7f647cc3a000 r-xp 00000000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cc3a000-7f647cd39000 ---p 007a8000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cd39000-7f647cd89000 rwxp 007a7000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cd89000-7f647ce42000 rwxp 00000000 00:00 0
7f647ce42000-7f647ce47000 r-xp 00000000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647ce47000-7f647d046000 ---p 00005000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647d046000-7f647d047000 rwxp 00004000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647d047000-7f647d049000 r-xp 00000000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d049000-7f647d249000 ---p 00002000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d249000-7f647d24a000 rwxp 00002000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d24a000-7f647d25b000 r-xp 00000000 00:14 8622561 /usr/lib/libXext.so.6.4.0Aborted
July 23, 2011, 05:52:03 PM
Latest git, on my 32bit Kubuntu 11.04 segfaults when executing "cgminer --help". GDB's backtrace returns:
Thanks very much for the backtrace! Fixed in git. Code:
#0 0x0024701a in strncpy () from /lib/i386-linux-gnu/libc.so.6
#1 0x08049e8d in show_algo (buf=0xbffff938 "\324\371\377\277t\332\022", algo=0x80714f8) at /usr/include/bits/string3.h:121
#2 0x0806c996 in opt_usage ()
#3 0x0806b509 in opt_usage_and_exit ()
#4 0x0806c5c5 in parse_one ()
#5 0x0806c1dc in opt_parse ()
#6 0x08050206 in main (argc=2, argv=0xbffffcb4) at main.c:3260
July 23, 2011, 05:45:23 PM
I get a segfault, too (on OS X 10.6.8 ).
Here's the output + command line:
And the trace:
Thanks! The backtrace helps to know why it segfaults (fixed in git now), but not why it's failing to create a command queue. I've tried backing out the compiler unloading patch as well in case that's the reason (changes are in git).Here's the output + command line:
Code:
cgminer-1.4.0> gdb --args ./cgminer --url http://pit.deepbit.net:8332 -u XXX -p XXX --url http://swepool.net-u XXX -p XXX -T
[2011-07-23 17:35:59] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
[2011-07-23 17:35:59] Creating Command Queue. (clCreateCommandQueue)
[2011-07-23 17:35:59] Failed to init GPU thread 0
[2011-07-23 17:35:59] Creating Command Queue. (clCreateCommandQueue)
[2011-07-23 17:35:59] Failed to init GPU thread 0
GPU 0: [0.0 Mh/s] [Q:0 A:0 R:0 HW:0 E:0% U:0.00/m]
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000038
text_print_status [inlined] () at main.c:738
738 printf(" %sPU %d: [%.1f Mh/s] [Q:%d A:%d R:%d HW:%d E:%.0f%% U:%.2f/m]\n",
Code:
(gdb) backtrace
#0 text_print_status [inlined] () at main.c:738
#1 print_status [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:804
#2 0x00000001000041ef in main (argc=1, argv=) at main.c:3516
Jump to: