OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[SAC]

Trying to get a Saphire 5970 to run up

I have 3 XFX Blk Edition untis that are working well

The Saphire just by itself will run for about 30 seconds and then White/blue screen  ...from reading it is being driven too hard

Here are the settings

cgminer --scrypt -o http://yourpool.com -u username -p password --thread-concurrency 8000,8000 -I 18,18 -g 1 -w 256,256

ATI drivers 12.8

What cgminer settings can you suggest to give it an easier time and also what clock & memory settings should i have as well ?

(This may not be relevant....if i run it as part of a 3 cards 1 of the GPU's goes SICK and then eveything crashes after 1-2 mins)

Try like I have it edited in your post and I use 780 for the engine memory at 1160 or 1185 depending on the card I have in use.


Edit: Also --auto-fan --auto-gpu added on the end could be of use to you. An example of the .conf file you can use to have most of these setting automatically applied on startup.

Code:

cat .cgminer/cgminer.conf-ltc
{
"pools" : [
{
        "url" : "http://yourpool.com:9332",
        "user" : "User.1",
          "pass" : "1"
},
{
                "url" : "stratum+tcp://yourpool.com:3333",
                "user" : "User.0",
                "pass" : "12345"
    },
    {
        "url" : "http://192.168.0.187:9332",
        "user" : "miners",
        "pass" : "litecoin"
    }
],

"auto-fan" : true,
"auto-gpu" : true,
"temp-target" : "79",
"gpu-fan" : "0-100",
"intensity" : "18,18,18",
"vectors" : "4,4,4",
"worksize" : "256,256,256",
"thread-concurrency" : "6720,8000,8000",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"donation" : "0",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

The script I use to start you want to be using the export commands regardless of using script to start..

Code:

cat ltc.sh
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export DISPLAY=:0
cd ~
cp .cgminer/cgminer.conf-ltc .cgminer/cgminer.conf

~/cgminer-2.10.4 --no-submit-stale --scrypt --api-listen --api-allow W:127.0.0.1,R:192.168.0.0/24 -g 1

The script to set the video speeds.

Code:

cat vset.sh
DISPLAY=:0 aticonfig --od-enable --adapter=all
DISPLAY=:0 aticonfig --od-setclocks=780,1160 --adapter=2
DISPLAY=:0 aticonfig --od-setclocks=780,1160 --adapter=1
DISPLAY=:0 aticonfig --od-setclocks=835,1185 --adapter=0
DISPLAY=:0 aticonfig --odgc --adapter=all

[1713272682]

1713272682

[1713272682]

1713272682

[1713272682]

1713272682

[1713272682]

1713272682

[YipYip]

Trying to get a Saphire 5970 to run up

I have 3 XFX Blk Edition untis that are working well

The Saphire just by itself will run for about 30 seconds and then White/blue screen  ...from reading it is being driven too hard

Here are the settings

cgminer --scrypt -o http://yourpool.com -u username -p password --thread-concurrency 8000,8000 -I 18,18 -g 1 -w 256,256

ATI drivers 12.8

What cgminer settings can you suggest to give it an easier time and also what clock & memory settings should i have as well ?

(This may not be relevant....if i run it as part of a 3 cards 1 of the GPU's goes SICK and then eveything crashes after 1-2 mins)

Try like I have it edited in your post and I use 780 for the engine memory at 1160 or 1185 depending on the card I have in use.


Edit: Also --auto-fan --auto-gpu added on the end could be of use to you. An example of the .conf file you can use to have most of these setting automatically applied on startup.

Code:

cat .cgminer/cgminer.conf-ltc
{
"pools" : [
{
        "url" : "http://yourpool.com:9332",
        "user" : "User.1",
          "pass" : "1"
},
{
                "url" : "stratum+tcp://yourpool.com:3333",
                "user" : "User.0",
                "pass" : "12345"
    },
    {
        "url" : "http://192.168.0.187:9332",
        "user" : "miners",
        "pass" : "litecoin"
    }
],

"auto-fan" : true,
"auto-gpu" : true,
"temp-target" : "79",
"gpu-fan" : "0-100",
"intensity" : "18,18,18",
"vectors" : "4,4,4",
"worksize" : "256,256,256",
"thread-concurrency" : "6720,8000,8000",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"donation" : "0",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

The script I use to start you want to be using the export commands regardless of using script to start..

Code:

cat ltc.sh
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export DISPLAY=:0
cd ~
cp .cgminer/cgminer.conf-ltc .cgminer/cgminer.conf

~/cgminer-2.10.4 --no-submit-stale --scrypt --api-listen --api-allow W:127.0.0.1,R:192.168.0.0/24 -g 1

The script to set the video speeds.

Code:

cat vset.sh
DISPLAY=:0 aticonfig --od-enable --adapter=all
DISPLAY=:0 aticonfig --od-setclocks=780,1160 --adapter=2
DISPLAY=:0 aticonfig --od-setclocks=780,1160 --adapter=1
DISPLAY=:0 aticonfig --od-setclocks=835,1185 --adapter=0
DISPLAY=:0 aticonfig --odgc --adapter=all

Thanks Dude..will give it a try tonight

[-ck]

Why would you use aticonfig when you can change the clocks directly with cgminer?

[SAC]

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

[-ck]

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

[SAC]

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

Sense or not it does it here is a machine I just put the proper values I need into the .conf and it appears to set the memory but not the engine to what I need and have specified.

Code:

miner4@miner4:~$ odg

Adapter 0 - ATI Radeon HD 5800 Series 
                            Core (MHz)    Memory (MHz)
           Current Clocks :    925           1185
             Current Peak :    925           1185
  Configurable Peak Range : [600-875]     [300-1200]
                 GPU load :    99%

Adapter 1 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    800           1160
             Current Peak :    800           1160
  Configurable Peak Range : [550-1000]     [300-1500]
                 GPU load :    99%

Adapter 2 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    800           1160
             Current Peak :    800           1160
  Configurable Peak Range : [550-1000]     [300-1500]
                 GPU load :    99%

Code:

miner4@miner4:~$ cat .cgminer/cgminer.conf
{
"pools" : [
....
],

"auto-fan" : true,
"auto-gpu" : true,
"temp-target" : "79",
"gpu-fan" : "0-100",
"intensity" : "18,18,18",
"gpu-engine" : "0-835,0-780,0-780",
"gpu-memclock" : "1185,1160,1160",
"vectors" : "4,4,4",
"worksize" : "256,256,256",
"thread-concurrency" : "6720,8000,8000",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"donation" : "0",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

[YipYip]

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

I have played around with the settings you guys have perscribed clock speed ,memory settings etc etc

I have tried 2 x MSI 890 FX mobo ATI 12.8 drivers...even took teh intensity down to 9 (it gave me 79k/hash for both GPU's ..lol )

The card no matter what after ~ 1 min white/blue/grey...gone

I have had 3 x XFX 5970's working fine in these boards etc... Can i safely say the card is dead

[SAC]

I have tried 2 x MSI 890 FX mobo ATI 12.8 drivers...even took teh intensity down to 9 (it gave me 79k/hash for both GPU's ..lol )

The card no matter what after ~ 1 min white/blue/grey...gone

I have had 3 x XFX 5970's working fine in these boards etc... Can i safely say the card is dead

Good chance of it although usually when dead they won't hash at all. Either that or one core will die on you, have had that happen as well.

[loshia]

Guy's

I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M.

And when cgminer eats all memory (45M) it takes about 2-3 days following happens

Feb  1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Kernel kills cgminer because system is running out of ram

Is there a way to reduce mem usage when cgminer is compiled for openwrt?

10X
PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM

[-ck]

Guy's

I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M.

And when cgminer eats all memory (45M) it takes about 2-3 days following happens

Feb  1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Kernel kills cgminer because system is running out of ram

Is there a way to reduce mem usage when cgminer is compiled for openwrt?

10X
PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM

Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.

[loshia]

Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.

Super!
My hash rate is about 9200 Mh/s on that host. Probably that is the reason why jgarzik has frequent restarts with his Avalon...

Thanks once again ..I am watching git closely and will compile/upgrade new version immediately and let you know how it goes
10X

[PatronDragon]

I use 2 videocards 7970 and 5870 but CGminer writes me that the incorrect file of a configuration! Write to me as the configuration file has to look correctly!

[CrazyGuy]

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

  curses.TUI...........: FOUND: -lncurses

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.

I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev

Code:

Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...

So is that the wrong version? (Still no love on the make clean / make) Any clue on how to get the 7.25.0+ version you speak of?
Thank you for your time.

It's still supposed to work with older curls. Somewhere it is thinking you have a later version installed which you don't. Anyway I usually install libcurl4-openssl-dev

I was getting the exact same compilation errors today upgrading from 2.9.6. Ubuntu 12.04 apt-get would not install higher than 7.22.0-3ubuntu4. Instead of messing around with it further, I just went ahead and updated to 12.10 and low and behold, i've now got version 7.27.0 of libcurl4-openssl-dev. CGminer compiles fine now.

[kano]

Just for anyone interested while I work on it.

https://github.com/kanoi/cgminer/commits/usb2
Hotplug (currently v0.1) for usbutils.c (that uses libusb) devices.

So far, the usbutils devices are BFL and MMQ
I've been doing all my testing with the BFL (no MMQ testing done yet)
Works fine as it is with BFL already ... and 'should' work with MMQ

All new devices that are built with usbutils.c will automatically be hotplug also.
(so that will include any ASIC drivers written by us)

I'll get around to converting the Icarus driver to usbutils one day ... to make ICA, CM1 & LOT hotplug also
(though that CM1 name will need a change ... maybe CMR)
But it's low on the priority at the moment, my todo list has quite a few things in it that I want to do
(including enhancements to this basic hotplug)

Edit:
1) When a usbutils device disappears it says on the screen "ZOMBIE" (not dead)
That's also automatic (like hotplug is)
API says No Device=true
2) Hotplug devices say a message on the screen like:
"Hotplug: BitForce added BFL 2"
3) The Hotplug devices don't show in the device list section of the curses screen
I haven't decided how to handle that yet

[loshia]

Kon,

I saw your memleak commit an i am testing it already.
However i am not sure though, there might be some other memleaks when calling pool_active which is happening quite often. I am attaching valgrind output just in case

The other stuff seemed not to be freed on cgminer exit which is not an issue:) Or i think so..
10X

==8359== HEAP SUMMARY:
==8359==     in use at exit: 908,508 bytes in 4,143 blocks
==8359==   total heap usage: 31,624 allocs, 27,481 frees, 41,232,886 bytes allocated
==8359==
==8359== 10 bytes in 2 blocks are definitely lost in loss record 24 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F7F0: extract_sockaddr (util.c:871)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 32 bytes in 1 blocks are definitely lost in loss record 73 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x403F4A: string_elist_add (miner.h:528)
==8359==    by 0x404C7F: add_serial (cgminer.c:507)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 35 bytes in 2 blocks are definitely lost in loss record 75 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F810: extract_sockaddr (util.c:872)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 44 bytes in 1 blocks are definitely lost in loss record 82 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 49 bytes in 1 blocks are definitely lost in loss record 89 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 160 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 161 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41C965: main (cgminer.c:6790)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 162 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41CBDD: main (cgminer.c:6850)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 163 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 531 (504 direct, 27 indirect) bytes in 1 blocks are definitely lost in loss record 176 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x405E0D: make_work (cgminer.c:1361)
==8359==    by 0x41CCEC: main (cgminer.c:6886)
==8359==
==8359== 727 (104 direct, 623 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 1,383 (104 direct, 1,279 indirect) bytes in 1 blocks are definitely lost in loss record 187 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 65,432 bytes in 1 blocks are definitely lost in loss record 210 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x425CF6: _io_new (api.c:652)
==8359==    by 0x42DC0D: api (api.c:3684)
==8359==    by 0x412662: api_thread (cgminer.c:4348)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 672,368 (104 direct, 672,264 indirect) bytes in 1 blocks are definitely lost in loss record 212 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== LEAK SUMMARY:
==8359==    definitely lost: 66,418 bytes in 12 blocks
==8359==    indirectly lost: 674,193 bytes in 3,866 blocks
==8359==      possibly lost: 1,152 bytes in 4 blocks
==8359==    still reachable: 166,745 bytes in 261 blocks
==8359==         suppressed: 0 bytes in 0 blocks
==8359== Reachable blocks (those to which a pointer was found) are not shown.
==8359== To see them, rerun with: --leak-check=full --show-reachable=yes
==8359==
==8359== For counts of detected and suppressed errors, rerun with: -v
==8359== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 2 from 2)
 valgrind --lea
ak-check=full ./cgminer --api-port 9999 --per-device-stats --api-
-network --api-listen  -S/dev/ICA0 --icarus-timing=1:38
==8748== Memcheck, a memory error detector
==8748== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8748== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8748== Command: ./cgminer xxxxxxxxxx --api-port 9999 --per-device-stats --api-network --api-listen -S/dev/ICA0 --icarus-timing=1:38
==8748==
 [2013-02-02 12:00:23] Started cgminer 2.10.4

[-ck]

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.

[loshia]

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.

I know:)
I was wondering if pool_active is causing any additional leak. That is why I posted all the output

[kano]

I have a memory.h overlay that I run on cgminer sometimes (that I wrote myself)
Although it uses 30x the RAM, it also includes an API call to list ALL calls to allocate RAM by filename/line of the code that allocated it, and stats about number allocated, free and number unfreed, amount allocated and freed etc etc (as well as various other very useful memory corruption tests)
I compile that in, once in a blue moon, to see if anything is allocating RAM and not freeing unnecessarily.
The output looks like this:

Code:

...
 cgminer.c:6403 a=1 f=0 d=1 ta=176 tf=0 td=176 ra=12288 rf=0 rd=12288
 cgminer.c:6405 a=21 f=0 d=21 ta=215 tf=0 td=215 ra=258048 rf=0 rd=258048
 cgminer.c:6457 a=1 f=1 d=0 ta=17 tf=17 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6475 a=1 f=1 d=0 ta=104 tf=104 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6480 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 miner.h:552 a=3 f=0 d=3 ta=96 tf=0 td=96 ra=36864 rf=0 rd=36864
 miner.h:553 a=3 f=2 d=1 ta=41 tf=34 td=7 ra=36864 rf=24576 rd=12288
 cgminer.c:1209 a=1 f=1 d=0 ta=20 tf=20 td=0 ra=12288 rf=12288 rd=0
 jansson/memory.c:0 a=99985 f=99656 d=329 ta=4264600 tf=4252207 td=12393 ra=1228644352 rf=1224601600 rd=4042752
 cgminer.c:1147 a=1027 f=1027 d=0 ta=13611 tf=13611 td=0 ra=12619776 rf=12619776 rd=0
 cgminer.c:416 a=12 f=0 d=12 ta=11904 tf=0 td=11904 ra=147456 rf=0 rd=147456
 cgminer.c:420 a=12 f=11 d=1 ta=720 tf=616 td=104 ra=147456 rf=135168 rd=12288
 util.c:896 a=13 f=0 d=13 ta=66 tf=0 td=66 ra=159744 rf=0 rd=159744
 util.c:897 a=13 f=0 d=13 ta=173 tf=0 td=173 ra=159744 rf=0 rd=159744
 util.c:583 a=47555 f=47548 d=7 ta=1864988 tf=1864784 td=204 ra=584355840 rf=584269824 rd=86016
 driver-icarus.c:573 a=2 f=0 d=2 ta=2304 tf=0 td=2304 ra=24576 rf=0 rd=24576
 driver-icarus.c:575 a=2 f=0 d=2 ta=26 tf=0 td=26 ra=24576 rf=0 rd=24576
 cgminer.c:6363 a=3 f=0 d=3 ta=192 tf=0 td=192 ra=36864 rf=0 rd=36864
 cgminer.c:6366 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 cgminer.c:6368 a=7 f=6 d=1 ta=280 tf=216 td=64 ra=86016 rf=73728 rd=12288
 driver-icarus.c:579 a=2 f=1 d=1 ta=40 tf=16 td=24 ra=24576 rf=12288 rd=12288
 driver-icarus.c:588 a=2 f=0 d=2 ta=1680 tf=0 td=1680 ra=24576 rf=0 rd=24576
 usbutils.c:535 a=1 f=0 d=1 ta=280 tf=0 td=280 ra=12288 rf=0 rd=12288
 usbutils.c:1108 a=2 f=0 d=2 ta=96 tf=0 td=96 ra=24576 rf=0 rd=24576
 driver-bitforce.c:173 a=1 f=0 d=1 ta=1152 tf=0 td=1152 ra=12288 rf=0 rd=12288
 usbutils.c:890 a=2 f=0 d=2 ta=144 tf=0 td=144 ra=24576 rf=0 rd=24576
 usbutils.c:893 a=2 f=0 d=2 ta=36 tf=0 td=36 ra=24576 rf=0 rd=24576
 usbutils.c:1021 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1028 a=2 f=0 d=2 ta=29 tf=0 td=29 ra=24576 rf=0 rd=24576
 usbutils.c:1035 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1267 a=5 f=4 d=1 ta=360 tf=240 td=120 ra=61440 rf=49152 rd=12288
 usbutils.c:1270 a=5 f=0 d=5 ta=70000 tf=0 td=70000 ra=122880 rf=0 rd=122880
 driver-bitforce.c:249 a=1 f=0 d=1 ta=28 tf=0 td=28 ra=12288 rf=0 rd=12288
...

Anyway, the point being, yep I do keep an eye on that every so often (or when someone suspects such a problem exists) and have found a couple in the past.

Edit: yes 'r' stands for real amount of ram (as opposed to 't' the requested amount) and yes the massive amount of RAM usage in jansson is almost entirely GBT

[loshia]

Kano,
Thank for your input.
I am not using GBT only stratum. The part of the problem may be related to latest kon git fix related to submitting stratum work. I am running latest git with fix and looks good for last 5 hours or so. I can be sure if that was major leak eating openwrt RAM after a day or two


Best

PS:if you can take a look at pool_active it will be great. I looked at it but there are some labels (jumps), and i do not know jsoon methods - which of them return pointer (no need to be freed) and which one of them return copies (like strdup). I suspect that in that function can be a memleak also but i am not sure

[kano]

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root      20   0 1282m 4228 2648 S  0.0  0.0   0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...