K3B locks up system

What I’ve been able to determine:

  1. it doesn’t matter which Blu-Ray drive I use. (I have a Pioneer BD-RW BDR-205 and a BDR-209D)

  2. The problem is intermittent – just a big PITB at the moment since I’m ripping a large part of my CD collection to FLAC for a “you beaut” new music device, so this part of the system is getting a lot more use than usual. I may try stopping and re-loading K3B after each 4
    or 5 CDs just to see if it may be some internal buffer that gets its knickers in a knot – I’ll follow up if it seems to be a fix.

  3. Even when SSH is configured and active the machine is locked tight when the lock-up occurs (the only fix is to either switch off/on or to use the reset switch)

  4. seems to be related to the reading of media, not writing

  5. just to be difficult, I’ve got an Nvidia graphics card with the Nvidia proprietary drivers Gforce GTX-560

  6. using leap 42.3 because when I tried to upgrade to 15, I kept getting a black screen lockup on boot – probably graphics related, but I couldn’t be stuffed trying to sort it after the third install attempt

  7. probably not relevant, but the machine has an 8 core AMD CPU, 32GB RAM, a 6TB RAID 5 home filesystem and 2 ssd drives for system files

There have been previous posts by others with similar problems, so I’m fairly sure that I’m not unique

Sorry to be following on to my own post, but…

I’ve managed to work now for a *lot longer than previously without a lock-up

The difference is that I am stopping and re-starting K3B after ripping about 5-6
CDs – what this is telling me is that there may be some data structure in the
program that corrupts after too many rips. (Note that the same thing happens
when copying multiple consecutive CDs.

Hopefully this will be some useful feedback to the developers.

Cheers,

-Don

Memory leak in k3b?

You could try to determine memory usage after e.g. each action to see if it increases. Should be about the same every time IMHO.

I suspect it uses tmp files maybe filling /tmp???

Possible, I’m using tmp filesystem with 32 GB RAM, so multiple rips could fill it, for sure. I’ll need to keep an eye on that Probably should delete tmp files on “Close” of rip, though.

Thanks

using “top -p 5024” where 5024 was the pid of k3b

                    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND

5024 don 20 0 1201048 122760 86812 S 0.000 0.374 0:01.93 k3b
5024 don 20 0 1966800 142680 94928 S 0.000 0.434 0:32.34 k3b
5024 don 20 0 1973624 155632 95340 S 0.000 0.474 1:05.89 k3b
5024 don 20 0 1973624 168432 95984 S 0.333 0.513 1:29.66 k3b
5024 don 20 0 1973624 169408 95988 S 0.000 0.516 1:59.11 k3b
5024 don 20 0 1973624 175172 95992 S 0.000 0.533 2:41.55 k3b

During a rip
5024 don 20 0 1967988 174892 98548 S 19.60 0.532 2:05.50 k3b

So, you’re absolutely correct that there does not seem to be a memory leak. But the reserved page set
seems to be growing, and thus the %MEM — a clue?