Unsupported operand types: string + int in dump.php if the VG has thin volumes

[S-trace]

PHP Fatal error: Uncaught TypeError: Unsupported operand types: string + int in dump.php:138 Stack trace: #0 {main} thrown in /home/s-trace/development/lvm2defrag/dump.php on line 138 An error occurs, fix it and try again.

[bisqwit]

I was not able to reproduce this error. What is the contents of your data.txt?

[S-trace]

data.txt Fix:

diff --git a/dump.php b/dump.php
index aaf83d9..2f377f8 100644
--- a/dump.php
+++ b/dump.php
@@ -135,7 +135,7 @@ foreach($vg as $vgname => $vgdata)
       if($offset > $begin)
         printf("(%d)\t%s\n", $offset-$begin, '-');
       printf("%d\t%s\n", $data['count'], $data['lv']);
-      $begin = $offset + $data['count'];
+      $begin = intval($offset) + $data['count'];
     }
     if($end > $begin)
       printf("(%d)\t%s\n", $end-$begin, '-');

[bisqwit]

Looks more like a plaster to me. I need information to reproduce the error.

[S-trace]

OS: Manjaro on x86-64 EFI Kernel: Linux 6.4.9-1-MANJARO #1 SMP PREEMPT_DYNAMIC PHP:

PHP 8.2.9 (cli) (built: Aug  1 2023 12:25:51) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.9, Copyright (c) Zend Technologies

I tried to run php dump.php manually, and it failed too.

I added printf("offset='%d'\n", $offset); before the $begin = $offset + $data['count']; and it prints the dump and then fails with the following:

...
offset='196429'
(145586)        -

! ***  ***
95389   SATAA-1
offset='0'
PHP Fatal error:  Uncaught TypeError: Unsupported operand types: string + int in /tmp/test/dump.php:139
Stack trace:
#0 {main}
  thrown in /tmp/test/dump.php on line 139

If I change %d to %s in format string it prints empty string before fatal error.

With intval($offset) dump,php prints nothing after SATAA-1, so intval() does not change behaviour of the script and its output, but just avoids the crash. It may be replaced by check if $offset is empty string or not and then (if it is empty) do break; or continue; to keep loop running

Maybe this problem is related to php version or php default settings?

Which information do you need?

[bisqwit]

See https://github.com/bisqwit/lvm2defrag/issues/5#issuecomment-1684086883

EDIT: Sorry. I didn’t notice you had attached the file. I will followup shortly.

[bisqwit]

I have confirmed your report using PHP 8.2. It does not occur with PHP 5.6. When setting error_reporting(E_ALL);, I am seeing these additional errors:

PHP Notice:  Undefined index: parts in /path/to/lvm2defrag/dump.php on line 65
PHP Notice:  Undefined index: parts in /path/to/lvm2defrag/dump.php on line 66

This is because lvm2degrag is not aware of the segment type thin-pool. Maybe it didn’t exist in 2011, when this tool was written. It appears to have been introduced in 2016. Unfortunately I don’t know how that feature works, and on a cursory examination no easy fix comes to mind. The problem you are experiencing appears to be closely connected: Because of the error that I quoted, pvoffs ends up null, so a blank string is used as a key in the array rather than the expected integer.

[S-trace]

I'm think I understood the problem. SATA is a thin volume in THIN LVM-Thin pool, and should be ignored in dump.php as sudo pvs -v --segments /dev/mapper/USB_LUKS does not list it and does not allow to move thin volumes (it allows to move LVM-Thin pool volumes (*-tdata and *-tmeta ones) itself, but not allow to move volumes allocated inside of the LVM-Thin pool)