[valgrind] [Bug 474160] If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors.
https://bugs.kde.org/show_bug.cgi?id=474160 --- Comment #2 from Eyal --- Let me know if there's anything that you'd like me to do here! The patch and testing is pretty straight-forward. I think that the new behavior will be more inline with valgrind user expectation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #16 from Eyal --- Created attachment 136346 --> https://bugs.kde.org/attachment.cgi?id=136346&action=edit path for expensive greater than comparisons -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #136346|path for expensive greater |patch for expensive greater description|than comparisons|than comparisons -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #18 from Eyal ---
>Interesting analysis, and a plausible patch; thank you for that. This seems
>like a new trick from LLVM.
Thanks. Yes
>* where's the addition instruction that merges the lanes together? I don't
> see that.
It's just beyond the part of the asm that I put in this post. I didn't include
it because it wasn't relevant to the bug. Here you go:
0x00401225 <+213>: movd %edx,%xmm2
0x00401229 <+217>: punpcklbw %xmm2,%xmm2
0x0040122d <+221>: punpcklwd %xmm2,%xmm3
0x00401231 <+225>: movzwl 0xa(%rsp,%rsi,1),%edx
0x00401236 <+230>: movd %edx,%xmm2
0x0040123a <+234>: punpcklbw %xmm2,%xmm2
0x0040123e <+238>: punpcklwd %xmm2,%xmm2
0x00401242 <+242>: pxor %xmm4,%xmm4
0x00401246 <+246>: pcmpgtd %xmm3,%xmm4
0x0040124a <+250>: psrad $0x18,%xmm3
0x0040124f <+255>: punpckldq %xmm4,%xmm3
0x00401253 <+259>: paddq %xmm0,%xmm3
That last line is the add.
>* what is the purpose of the pcmpgtd instruction? The original sources
> contain a scalar comparison against zero
For sign-extension. Because the numbers are 8-bit characters (char) but the
output is 32-bit signed (int), we need to sign extend the char. The comparison
of 0>$xmm3 is filling the register with 1s if the number is negative. The
following psrad does an arithmetic shift, sign extending the negative to fill
the 24-bit difference. You can see the paddq below it. I didn't analyze it
too much; I trust the LLVM people know what they're doing.
if (hp==j) {
j++;
}
> Is that related? If so, how does a scalar 32-bit equality test against zero
> get translated into a vector 32x4 signed-greater-than operation?
Later in the code the vector eventually gets collapsed into a single value,
like we need. This comparison is what causes the error because memcheck only
reports the error when the value gets used in a branch, not when it's created.
I could have also returned the sum; that would have worked as well.
---
>In the patch, there's mention of biasing:
>
>+ // From here on out, we're dealing with biased integers instead of 2's
>+ // complement.
>
>What does that mean, in this context?
Probably just bad wording on my part. What I should have just said is that the
MSB of a signed number is 0 for positive and 1 for negative so to get the max
or min value, we need to invert the MSB with xor. Or another way to think
about it is that we convert the number space from 2's complement, where the
0x00 is 0 and 0xff is -1, to a "biased" space where 0x00 is -128, 0x7f is -1,
0x80 is 0, 0x81 is 1, all the way up to 0xff which is 127. Each number is
stored in bits as it's value +128. Writing numbers that way fixes the problem
of 2's complement were a 1 in the MSB is *less* than a 0 in the MSB.
I will remove the confusing explanation and instead just mention the MSB thing.
>* you put it in memcheck/tests/x86; "x86" here means 32-bit only. Is that
> what you intended? I would have expected it to go in the "amd64" directory.
I'll fix that.
>* because the test is written in C, whether or not it tests what you expect it
> to test depends entirely on the compiler used to compile it. And most
> likely, it won't be vectorised, or won't be vectorised in the same way.
> This kind of test really needs to be written in assembly (inline assembly)
> so we know what we're testing.
Yes. For that reason I put the binary in the patch! That was bad. I'll use
asm instructions. I had a bad time with them when I was debugging but I'll
figure it out. Also, I'll be able to test more of the edge cases.
There were bugs in the original patch anyway. It's a delicate bit of code.
Because it's only for Intel SSE2 processors, if I put the test in the amd64
directory, is that enough to ensure that only the SSE2-enabled chips will run
the test?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #136346|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #19 from Eyal --- Comment on attachment 136346 --> https://bugs.kde.org/attachment.cgi?id=136346 patch for expensive greater than comparisons Obsolete now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #20 from Eyal --- Created attachment 136381 --> https://bugs.kde.org/attachment.cgi?id=136381&action=edit patch with tests -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #21 from Eyal --- Will anyone consider the patch? There might be a lot of false positives out there now that clang is doing this optimization and it would be nice to catch them before many users waste a lot of time on this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #23 from Eyal --- Generalizing the patch to handle different bit widths would be easy. In fact, that's why I wrote it using a switch statement with just one case. To generalize it you just need to add cases into the switch statement. Pretty easy. Another generalization that you didn't mention is covering not just greater-than but also less-than and equality. I didn't code up all those alternatives because there are no such opcodes in x86 SSE2. So even if I did it, I couldn't test it. If there are bug reports around vector equality, let me know! I think that I understand this part of the code pretty well by now and also how to test it so I could be helpful there. Send links. I discovered this bug because the CI system on GitHub upgraded clang to v10 and it broke my testing. As more operating systems upgrade their compiler, there will be more and more of these errors. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #24 from Eyal --- Created attachment 136575 --> https://bugs.kde.org/attachment.cgi?id=136575&action=edit patch that supports pcmpgtX for 64/32/16/8 bit This one is more complex but it supports all the different pcmpgt* instructions in x86. The 8-bit one is a little strange, though. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #25 from Eyal --- Created attachment 136599 --> https://bugs.kde.org/attachment.cgi?id=136599&action=edit patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates This one uses c++ in the test only. It is a much more thorough test because it tests all lanes of the SIMD register. It uses templates so the code is smaller. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with version
https://bugs.kde.org/show_bug.cgi?id=472881 Eyal changed: What|Removed |Added Summary|Grouping/Versioning: add|Grouping/Versioning: add |grouping by filename with |grouping by filename with |versioning |version -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472879] Grouping: add Group to main Items menu
https://bugs.kde.org/show_bug.cgi?id=472879 --- Comment #2 from Eyal --- Two additional advantages: 1. As Maik has pointed out (in another bug), main-menu items are available as toolbar actions (ie. can be added as toolbar buttons). 2. Similarly, main-menu items can be assigned keyboard shortcuts. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #51 from Eyal --- I'll take a look. I gotta say, this patch is super annoying. I've been working on it for 2.5 years now? Instead of github, emails. And no CI. :-( I've resorted to my own personal branch of valgrind with all my fixes. I'll make one last push here. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #52 from Eyal --- Y'all need CI, I can't even build the master branch. :-( -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #54 from Eyal --- (In reply to Mark Wielaard from comment #53) > (In reply to Eyal from comment #52) > > Y'all need CI, I can't even build the master branch. :-( > > We do have CI against various distros and arches: > https://builder.sourceware.org/buildbot/#/builders?tags=valgrind > And although some tests are failing it does seem to build everywhere. > What is wrong with the build for you? How does it fail? Good to know that there is CI. I'm bisecting the build failure now... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #55 from Eyal --- (In reply to Eyal from comment #54) > (In reply to Mark Wielaard from comment #53) > > (In reply to Eyal from comment #52) > > > Y'all need CI, I can't even build the master branch. :-( > > > > We do have CI against various distros and arches: > > https://builder.sourceware.org/buildbot/#/builders?tags=valgrind > > And although some tests are failing it does seem to build everywhere. > > What is wrong with the build for you? How does it fail? > > Good to know that there is CI. > > I'm bisecting the build failure now... Alright, it was just that I forgot to run autogen.sh. It's fine now. I can't get those failing sse tests to even build. Is it possible that my reasonably-modern computer doesn't support sse2? When I run make in the directory memcheck/tests/x86, nothing gets built! How do I fix this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #56 from Eyal --- I was able to get the tests to build and pass on master by running `sudo apt-get install libc6-dbg:i386` and `sudo apt-get remove libc6-dbg`. I guess that this is an x86 and not amd64 problem only? I'm able to reproduce the problem now and I'll try to figure out what's going on! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #57 from Eyal --- I've identified the problem and I hope to have a solution, soon. It is based on a similar solution for AMD64. Both platforms to not have an xmm shift with lane size of 8. I'll update the patch and also add test cases for x86. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #139036|0 |1 is obsolete|| --- Comment #58 from Eyal --- Created attachment 161402 --> https://bugs.kde.org/attachment.cgi?id=161402&action=edit c++ patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates I fixed support for x86. To test for x86 on an amd64 computer, run these: sudo apt-get install gcc-multilib g++-multilib sudo apt-get install libc6-dbg:i386 sudo apt-get remove libc6-dbg And then recompile and run tests. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 474160] New: If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors.
https://bugs.kde.org/show_bug.cgi?id=474160 Bug ID: 474160 Summary: If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors. Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: eyals...@gmail.com Target Milestone: --- SUMMARY *** `exit-on-first-error` should *not* exit on any error that is not listed in the `errors-for-leak-kinds` list. *** STEPS TO REPRODUCE 1. Build and install in the usual way: ./autogen.sh && ./configure --prefix=$HOME/.local && make -j 20 && make -j 20 check && make install 2. From root directory of valgrind, run: valgrind --error-exitcode=127 --errors-for-leak-kinds=definite --leak-check=full -s --exit-on-first-error=yes memcheck/tests/leak-cases OBSERVED RESULT Despite setting errors-for-leak-kinds to "definite", the test is exiting on a non-"definite" leak. EXPECTED RESULT The test should only exit on leak types listed in the errors-for-leak-kinds. If that list is empty only then should it exit on all types of leaks. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 3.22 git commit c086bbdd6 ADDITIONAL INFORMATION More details here: https://github.com/eyal0/valgrind/pull/5#issuecomment-1705724572 Working fix with unit test here: https://github.com/eyal0/valgrind/pull/5/files -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 474160] If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors.
https://bugs.kde.org/show_bug.cgi?id=474160 --- Comment #1 from Eyal --- Created attachment 161405 --> https://bugs.kde.org/attachment.cgi?id=161405&action=edit patch with working code and unit test This fixes the issue and adds a unit test. Also here: https://github.com/eyal0/valgrind/pull/5/files -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #136381|0 |1 is obsolete|| Attachment #136575|0 |1 is obsolete|| Attachment #161402|0 |1 is obsolete|| --- Comment #60 from Eyal --- Created attachment 161418 --> https://bugs.kde.org/attachment.cgi?id=161418&action=edit c++ patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates Re-made the amd64 expected output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #61 from Eyal --- (In reply to Paul Floyd from comment #59) > You forgot to update the expecteds (I saw that just the line numbers have > changed), and I had to convert the text .cpp files into symlinks (does Linux > / GCC accept a plain text .cpp file that just contains a path?). > > On FreeBSD 13.2 amd64 with clang 14 I get > > == 830 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == Right you are! I made the patch again: https://bugs.kde.org/attachment.cgi?id=161418 It is normal for git to store a symlink as a small file with just a path in it. Did you apply the patch using `git am` or using `patch`? I created the patch using `git format-patch` and if you apply it with `git am` then it should properly handle the symlink. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 462443] Crash when renaming a file
https://bugs.kde.org/show_bug.cgi?id=462443 --- Comment #2 from Eyal --- (In reply to Akseli Lahtinen from comment #1) > Have you encountered this bug again on newer version of dolphin? > > Also if you have, can you send a backtrace with debug symbols: > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Arch_Linux No, I no longer encounter this issue. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 462443] Crash when renaming a file
https://bugs.kde.org/show_bug.cgi?id=462443 Eyal changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added CC||eyals...@gmail.com --- Comment #5 from Eyal --- I have been getting a report about "Conditional jump or move depends on uninitialised value(s)" in the project pcb2gcode that only happens on clang and not gcc, like this one. My bug started when github continuous integration switched from clang version 9 to clang version 10. On a hunch, I tried this code with both old and new clang. It's the same here: old clang does not report an error but new clang does. gcc: no error clang version 7: no error clang version 10: error Not sure if that's useful to you in debugging. You might compare disassembly of different versions of clang. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #6 from Eyal ---
Here's one that also fails but with a different error:
==12859== Syscall param exit_group(status) contains uninitialised byte(s)
==12859==at 0x492F9D6: _Exit (_exit.c:31)
==12859==by 0x48A2E89: __run_exit_handlers (exit.c:132)
==12859==by 0x48A2EB9: exit (exit.c:139)
==12859==by 0x488D0A1: (below main) (libc-start.c:342)
==12859== Uninitialised value was created by a stack allocation
==12859==at 0x401030: ??? (in /tmp/a.out)
// clang -W -Wall -g -O2 Standalone.c && valgrind --track-origins=yes ./a.out
#include
#include
int main()
{
{
struct sigaction act;
if (sigaction(SIGTERM, 0, &act) < 0) {
return 1;
}
if (sigaction(SIGTERM, 0, &act) < 0) {
return 1;
}
}
char pattern[] = "123456786";
pattern[2] = '4';
const unsigned long plen = strlen(pattern);
size_t hp=0;
for (size_t i = 1; i < plen; ++i)
hp += pattern[i];
if (hp)
return 1;
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #7 from Eyal --- It seems that the issue is the loop. When the length of pattern is more than 8, the code runs a routine that is able to sum 8 chars at a time. It uses xmm for this. It only enters that code if the number of bytes to sum is at least 8. I'm not sure why removing the call to sigaction matters. Maybe it's an alignment issue? Removing the `pattern[0] = '1'` allows the compiler to figure out that the pattern is a constant and the whole thing gets evaluated at compile-time, as if constexpr. That explains why the line is necessary to cause the bug. The routine to sum 8 bytes at once seems really long to me but I guess clang has decided that it's faster than doing extra jumps. If I can figure out how to have valgrind display the bit-validity values during processing, maybe I can see which instruction is getting instrumented incorrectly. I feel that this is a valgrind bug, not a clang bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #8 from Eyal ---
Even vgdb isn't helping me. Here's the code that I'm using:
#include
#include
#include
#include
int main()
{
struct sigaction act;
if (sigaction(SIGTERM, 0, &act) == 1) {
return 12;
}
if (sigaction(SIGTERM, 0, &act) == 1) {
return 12;
}
char pattern[] = "0123456789";
pattern[8] = 0;
const unsigned long plen = strlen(pattern);
size_t hp=0;
for (size_t i = 0; i < plen; ++i)
hp += pattern[i];
volatile int j = 0;
if (hp==j) {
j++;
}
return 1;
}
If I switch the pattern[8] with pattern[9] then the output is nearly identical
but it fails a memcheck test in valgrind.
I used vgdb to step through the code and I'm seeing strange behavior. In the
code, there are two instances of movq to an xmm register:
0x004011ff <+191>: je 0x4012c8
0x00401205 <+197>: mov%rbx,%rdi
0x00401208 <+200>: sub%rsi,%rdi
0x0040120b <+203>: movq %r8,%xmm0
and
0x004012c8 <+392>: movq %r8,%xmm0
Identical instructions. Depending on the pattern[] line above, either the jump
is taken or not. In either case, eventually there is a movq from register r8
into xmm0.
In the working case, I see that $r8 is successfully copied into $xmm0 and the
vbits are all cleared to 0, as it expected. But in the broken case, the value
is not copied and the vbits are wrong, too! It might just be wrong when
looking at the result in vgdb because the output is right in the end.
If someone can help me debug this, I'm willing to put in some time.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #9 from Eyal ---
Oops, I spoke to soon. It's a bug in clang. Here's code that you can try:
#include
#include
#include
#include
void foo() {
// Put the garbage number 123 into eax.
// It's caller-saved so no problem.
__asm__ ("lea 123, %eax;");
// xmm variables are all caller-saved, too.
// Fill them with garbage.
__asm__ ("movd %eax, %xmm0");
__asm__ ("punpcklbw %xmm0, %xmm0");
__asm__ ("punpcklbw %xmm0, %xmm0");
__asm__ ("punpcklbw %xmm0, %xmm0");
__asm__ ("punpcklbw %xmm0, %xmm0");
__asm__ ("movd %eax, %xmm1");
__asm__ ("punpcklbw %xmm1, %xmm1");
__asm__ ("punpcklbw %xmm1, %xmm1");
__asm__ ("punpcklbw %xmm1, %xmm1");
__asm__ ("punpcklbw %xmm1, %xmm1");
__asm__ ("movd %eax, %xmm2");
__asm__ ("punpcklbw %xmm2, %xmm2");
__asm__ ("punpcklbw %xmm2, %xmm2");
__asm__ ("punpcklbw %xmm2, %xmm2");
__asm__ ("punpcklbw %xmm2, %xmm2");
__asm__ ("movd %eax, %xmm3");
__asm__ ("punpcklbw %xmm3, %xmm3");
__asm__ ("punpcklbw %xmm3, %xmm3");
__asm__ ("punpcklbw %xmm3, %xmm3");
__asm__ ("punpcklbw %xmm3, %xmm3");
__asm__ ("movd %eax, %xmm4");
__asm__ ("punpcklbw %xmm4, %xmm4");
__asm__ ("punpcklbw %xmm4, %xmm4");
__asm__ ("punpcklbw %xmm4, %xmm4");
__asm__ ("punpcklbw %xmm4, %xmm4");
}
int main() {
char pattern[] = "0123456789";
pattern[9] = 0;
const unsigned long plen = strlen(pattern);
foo();
size_t hp=0;
for (size_t i = 0; i < plen; ++i)
hp += pattern[i];
volatile int j = 0;
if (hp==j) {
j++;
}
printf("%ld\n", hp);
return 1;
}
Run this with and without foo commented and see that the results are different.
No valgrind need.
Testing on godbolt, I see that the bug is present even through clang 11.0.1
https://godbolt.org/z/6s1rTd
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #11 from Eyal --- I'm back to not being sure if this is an llvm issue. There are a few things at play here. One is sigaction(), which can foul up the the contents of xmm registers, especially xmm3, which is the only register that isn't specifically cleared out by the loop. The other issue is clang, which isn't specifically clearing out xmm3 but it sort of is doing thing that happen to clear it out. I'm still investigating. And finally, there is valgrind, which might just not know enough about an operation in order to determine that, yes, it's legal. I feel like I'm making progress. I'll update with more as I go along. If I do find that it is a memcheck problem in clang, is there someone that can help me write a software patch for valgrind? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #12 from Eyal ---
Okay, now I'm back to thinking that it's a valgrind issue. But it's nothing
that valgrind can fix. Here's the problematic asm code:
movd %edx,%xmm2 (1)
punpcklbw %xmm2,%xmm2 (2)
punpcklwd %xmm2,%xmm3 (3)
movzwl 0xa(%rsp,%rsi,1),%edx
movd %edx,%xmm2 (4)
punpcklbw %xmm2,%xmm2
punpcklwd %xmm2,%xmm2
pxor %xmm4,%xmm4 (5)
pcmpgtd %xmm3,%xmm4(6)
psrad $0x18,%xmm3
This code is some SIMD math that gets made for summing the characters in a
string, like in the original code. Before this code, the calls to sigaction
have inadvertently fouled up the contents of the xmm registers. That's okay,
sigaction is allowed to do that because xmm registers are caller-saved. That
means that if the caller wanted them to have valid info, it was up to the
caller to save and restore them beforehand. No problem.
For the below explanation, we'll use letters (ABCD) for known bytes, X for
unknown bytes, and 0 for 0 bytes.
(1) is putting a known value into xmm2. So xmm2 is now well-defined as
ABCD
(2) is bytewise interleaving the value in xmm2 with itself. So xmm2 is now
AABBCCDD.
(3) is wordwise (16b) interleaving xmm2 with xmm3. xmm3 is now
AAXXBBXXCCXXDDXX.
(4) notice that xmm2 has been clobbered with a new value.
(5) xmm4 is set to all 0:
(6) is doing a signed double-word (32-bit) SIMD comparison of xmm3 and xmm4 and
putting the result as a 0 or -1 into xmm4. If the xmm4 value is bigger than
the xmm3 value, the xmm4 double-word will be filled with ones. Otherwise,
zero. The comparison looks like this (MSB-first):
> AAXX ? -1 : 0
> BBXX ? -1 : 0
> CCXX ? -1 : 0
> DDXX ? -1 : 0
Considering the ABCDs:
* If they are negative then the MSB is a 1 and zero is greater than all
negative numbers so we don't need to look any further.
* If they are positive then the whole number is positive and we don't need to
look any further.
* If they are zero then the number is either 0 or positive. Either way, 0 is
not greater than a non-negative number so we don't need to look any further.
So as far we're considered, the output here is completely defined!
valgrind memcheck doesn't track values, though, only whether or not a value was
explicitly defined. So valgrind is seeing this:
QRST > AAXX ? -1 : 0
All the letters (other than X) are defined but valgrind's mechanism doesn't
keep track of whether or not they are zero. Because it doesn't know that Q is
a 0, it might be that QR match AA! In which case, the only way to know the
result is to know how ST compares to XX. And XX is unknown so the result is
unknown. The "undefinedness" propagates all the way to a branch statement
later in the code which valgrind detects and reports.
---
In (4) above, we see that xmm2 is clobbered quickly after it's use in (1,2,3).
So why use it anyway? Also, lots of the other code doesn't use xmm2 as a
scratchpad:
movd %edx,%xmm2
punpcklbw %xmm2,%xmm2
punpcklwd %xmm2,%xmm2
movd %edx,%xmm0
punpcklbw %xmm0,%xmm0
punpcklwd %xmm0,%xmm0
movd %edx,%xmm1
punpcklbw %xmm1,%xmm1
punpcklwd %xmm1,%xmm1
So why not do the same here?
If I write this code and compile it:
void asm_test() {
__asm__ ("movd %edx, %xmm2");
__asm__ ("punpcklbw %xmm2, %xmm2");
__asm__ ("punpcklwd %xmm2, %xmm3");
__asm__ ("movd %edx, %xmm3");
__asm__ ("punpcklbw %xmm3, %xmm3");
__asm__ ("punpcklwd %xmm3, %xmm3");
}
And then objdump -D on it:
401697: 66 0f 6e d2 movd %edx,%xmm2
40169b: 66 0f 60 d2 punpcklbw %xmm2,%xmm2
40169f: 66 0f 61 da punpcklwd %xmm2,%xmm3
4016a3: 66 0f 6e da movd %edx,%xmm3
4016a7: 66 0f 60 db punpcklbw %xmm3,%xmm3
4016ab: 66 0f 61 db punpcklwd %xmm3,%xmm3
I can see that the instruction sizes are the same. So I can use emacs
hexl-mode or xxd or objdump -R to modify the binary and try it. It only took a
moment and it solved the problem. Valgrind no longer reports any errors.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #13 from Eyal --- https://bugs.llvm.org/show_bug.cgi?id=49372 I hope that LLVM can help us out here! I think that it would be nice. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #14 from Eyal --- A possible solution in Valgrind: https://github.com/eyal0/valgrind/commit/899ea491e358013579f87e443beff0a30c69e348 This improves Valgrind's check for definedness when doing 32x4 SIMD signed greater than. It solves the problem for the test case below. If you can, consider testing if it solves the problem for your original code. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #47 from Eyal --- Any progress here? I see the valgrind is getting new commits all the time. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #27 from Eyal --- Maybe that's with the c code. I wrote a version in c++ which is uses templates to make the test code much shorter. Let's focus on just one of them so that I don't have to duplicate too much work. Do we want c++ for the test code or only c? Either will work but the c++ is shorter. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #29 from Eyal --- Okay. I don't think that I'm using any special features of c nor c++... How would I know? Is there some test that I can run? I didn't find any errors when I compiled with -Wall -Werror so I didn't see that string being converted to a char *. Maybe that was with an older patch that wasn't the latest c++ one? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #45 from Eyal --- Sure, let me know if I can be of assistance. This was an actual issue for me with false positives in boost in newer clang. Boost is quite popular so I imagine that as more people upgrade to newer clang, maybe more of them will hit these errors. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 --- Comment #12 from Eyal --- But this one is not merged: https://bugsfiles.kde.org/attachment.cgi?id=162566 Should it be merged? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #63 from Eyal --- I think that you could have used 'git apply' also. Anyway, I hope that the tests are all passing now and perhaps we can make progress on the patch? Eyal On Wed, Sep 6, 2023, 23:39 Paul Floyd wrote: > https://bugs.kde.org/show_bug.cgi?id=432801 > > --- Comment #62 from Paul Floyd --- > OK didn't know that (or had forgotten). I think I tried git patch which > didn't > like the formatted patch and then my usual fallback 'patch -p1 < patchfile' > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #65 from Eyal --- Yeah, I saw that you have been busy with that! Do you prefer that I go through the process of pushing a branch for CI? I need to get added with some permissions? Eyal On Sun, Sep 10, 2023, 10:02 Paul Floyd wrote: > https://bugs.kde.org/show_bug.cgi?id=432801 > > --- Comment #64 from Paul Floyd --- > > > I think that you could have used 'git apply' also. Anyway, I hope that > the > > tests are all passing now and perhaps we can make progress on the patch? > > It's next on my list! > > Been very busy this weekend updating one of the FreeBSD packages and > fixing an > issue with aligned_alloc and glibc 2.38. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #68 from Eyal --- Thanks for doing this! Now this one: https://bugs.kde.org/show_bug.cgi?id=474160 ? Eyal On Tue, Sep 19, 2023 at 11:33 AM Paul Floyd wrote: > https://bugs.kde.org/show_bug.cgi?id=432801 > > Paul Floyd changed: > >What|Removed |Added > > > Resolution|--- |FIXED > Status|REPORTED|RESOLVED > > --- Comment #67 from Paul Floyd --- > Many thanks! > > commit 26a3abd27db2ef63dafea1ecab00e8239f341f0f (HEAD -> master, > origin/master, > origin/HEAD) > Author: Eyal Soha > Date: Thu Feb 10 09:52:54 2022 -0700 > > Bug 432801 - Valgrind 3.16.1 reports a jump based on uninitialized > memory > somehow related to clang and signals > > Add support for precise computation of SIMD greater-than on > amd64 and x86. > > This adds support for 64bit, 16bit, and 8bit to the existing 32bit > support. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Eyal changed: What|Removed |Added CC||eyals...@gmail.com --- Comment #5 from Eyal --- I'll write some details to explain what is going on here. In this commit: 26a3abd27db2ef63dafea1ecab00e8239f341f0f The handling of pcmpgt was improved. The pcmpgt operation takes two 128-bit registers and treats every (8/16/32/64) bits as a separate word and then is tests them for "greater than". Before the commit 26a3abd2, valgrind just looked for any undefined bits in one or the other register and said that if some all undefined then the whole result is undefined. valgrind was doing the wrong thing. This caused false positives for me in a newish version of clang so I put in the expensive check which now calculates the "greater than" despite undefinedness and does the best possible computation. Unrelated to that fix, the vbits test checks that vbits work correctly. It tests operations and checks that the vbits generated are correct. For many operations, it's too hard to generate the correct vbits off an input so the operation is marked as "UNDEF_UNKNOWN", indicating that the vbits for that operation are too hard to calculate so we just won't test this one. All the Iop_CmpGT... operations ( there are 2-0 of them) in the vbits test are marked as "UNDEF_UNKNOWN" except for Iop_CmpGT64Ux2. This was probably a mistake when it was written. For that one, it checks that the vbits that are output are doing the wrong thing in the way that valgrind also does the wrong thing. Basically, it was confirming that valgrind is doing the wrong thing in the way that we expect valgrind to be wrong. Well, now valgrind works and so the test is getting hung up because it's checking that valgrind is still "broken". But it isn't. I never noticed this in my testing because it only tested on ppc platforms. The solution is to first set that test to UNDEF_UNKNOWN. That'll get the tests working again. The follow-up, if we want, is to convert all those UNDEF_UNKNOWNS into UNDEF_somethingelse that actually checks correctness. Now, is that the right thing to do? Maybe. On the one hand, it makes the testing more complete. On the other hand, the guy that wrote the expensiveCmpGT (me) is going to write the UNDEF_CMP_GT (me again) it's like me grading my own homework and declaring 100% on myself. Not a very robust test! However, the vbits code is in regular c++ and not the VEX IR thing so there is some value to it that way. And I can see in the vbits test that ADD, SUB, etc, *are* handled (not UNDEF_UNKNOWN) and cmpgt is similar to those. So maybe we should do it. I think that it wouldn't be too difficult to do given that we can pretty much copy the ADD and SUB examples. We'll need permuations for the various bit widths, signed/unsigned, and number of lanes. But not too bad. I'd probably still skip the floating point ones because that seems harder to me. Maybe it's not, though? I dunno. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 --- Comment #6 from Eyal --- Created attachment 162550 --> https://bugs.kde.org/attachment.cgi?id=162550&action=edit Fix vbits for cmpgtExB where E*B==128 This adds more precise testing to the vbits program. Only amd64 is enabled. Add .ppc32=1 or .ppc64=1 to some of those and run to see if they work. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025
--- Comment #8 from Eyal ---
I completed the new tests. Please try adding ppc platforms and test them. I
already added amd64 testing for a few of them.
On Wed, Oct 25, 2023, 09:37 Carl Love wrote:
> https://bugs.kde.org/show_bug.cgi?id=476025
>
> --- Comment #7 from Carl Love ---
> The test for the Iop_CmpGT64Ux2 was changed as follows:
>
> diff --git a/memcheck/tests/vbit-test/irops.c
> b/memcheck/tests/vbit-test/irops.c
> index a09470905..e94ea2432 100644
> --- a/memcheck/tests/vbit-test/irops.c
> +++ b/memcheck/tests/vbit-test/irops.c
> @@ -861,7 +861,7 @@ static irop_t irops[] = {
>{ DEFOP(Iop_CmpGT8Ux16, UNDEF_UNKNOWN), },
>{ DEFOP(Iop_CmpGT16Ux8, UNDEF_UNKNOWN), },
>{ DEFOP(Iop_CmpGT32Ux4, UNDEF_UNKNOWN), },
> - { DEFOP(Iop_CmpGT64Ux2, UNDEF_ALL_64x2), .ppc64 = 1, .ppc32 = 1 },
> + { DEFOP(Iop_CmpGT64Ux2, UNDEF_UNKNOWN), },
>{ DEFOP(Iop_Cnt8x16, UNDEF_UNKNOWN), },
>{ DEFOP(Iop_Clz8x16, UNDEF_UNKNOWN), },
>{ DEFOP(Iop_Clz16x8, UNDEF_UNKNOWN), },
> --
> The commit was:
>
> commit bb162ac6c082f371da90fb3691f3185a53c2d56f (HEAD -> master,
> origin/master,
> origin/HEAD)
> Author: Carl Love
> Date: Wed Oct 25 11:20:30 2023 -0400
>
> Change the vbit test specification for Iop_CmpGT64Ux2
>
> The test should be specified as UNDEF_UNKNOWN not UNDEF_ALL_64x2.
> No architectures should be enaabled for the test.
>
> This effectively disables the vbit test on all architectures. Note the
> Iop_CmpGT* for the other sizes are already set to UNDEF_UNKNOWN. None of
> the
> Iops are getting tested at the current time.
>
> TO DO, work on adding appropriate testing for this class of Iops. Eyal has
> started on the new tests.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Eyal changed: What|Removed |Added Attachment #162550|0 |1 is obsolete|| --- Comment #9 from Eyal --- Created attachment 162566 --> https://bugs.kde.org/attachment.cgi?id=162566&action=edit Fix vbits for cmpgtExB where E*B==128 rebased onto bb162ac6c Same fix as before, rebased on to the latest of master branch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 Eyal changed: What|Removed |Added CC||eyals...@gmail.com --- Comment #4 from Eyal --- For each operand, we run multiple tests with various settings of value and vbits. A test ought to look like this: 1. Create variables aa and bb and vaa and vbb. 2. Set the vbits of aa and bb to be vaa and vbb, respectively. 3. Run that operand on aa and bb. 4. Extract the vbits that valgrind computed on the result. And for a check, we do this: 1. Run a helper function whose input is aa,bb,vaa, and vbb. 2. That helper function computes the vbits that we expect in the output of the operand. Finally, we compare the expected vbits against what valgrind came up with. In the function valgrind_execute_test, we set the vbits of aa and bb before we run the operand. That part is fine. But when we run the helper with the inputs aa,bb,vaa,vbb, there is no uncertainty there. We have, in fact, extracted the uncertainty from aa and bb into vaa and vbb and now, aa and bb have no uncertainty. They should have vbits 0, both of them. It's now up to the helper function to use the definite values of aa,bb,vaa, and vbb to compute the definite expected vbits of the operand. It would be easy to check. Just add a loop over the operands into check_result_for_binary that does this: opnd->vbits.bits = 0; valgrind_set_vbits(opnd); Maybe like 5 lines of code total? I don't have the right platform to test this out, though... If I make a patch, would someone like to test it? Eyal -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #5 from Eyal --- Like I said before: As part of the tests, some vbits get set. However, we need to clear them again before we compute the expectation or else the expectation *itself* will have vbits set in it. The expectation should have none. I'm unable to reproduce this myself but maybe someone else can test it? Thanks. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #6 from Eyal --- Created attachment 162607 --> https://bugs.kde.org/attachment.cgi?id=162607&action=edit This might fix the problem and it's the solution that I prefer. This might fix the problem and it's the solution that I prefer. After we set the vbits in order to run the test, reset them right after. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #7 from Eyal --- Created attachment 162608 --> https://bugs.kde.org/attachment.cgi?id=162608&action=edit This might fix it, too, but I prefer the other one. We refactor the code so that the computation is done before the vbits are set. And then we clear out all the vbits before we do the comparison. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #8 from Eyal --- Drawing up the truth table of those two versions of calculating a_min, I find that only the case when aa is unknown and vaa is 1 make any difference. The output in the version aa & ~vaa return 0 is aa==x and vaa==1. But for (aa&vaa)^aa, it gets unknown. Note that, if vaa is 1, the expression simplifies to (aa&1)^aa, which is just aa^aa, which is always 0 but the way that valgrind works, it can't recognize that the x on the left and the x on the right are the same x so its failing. We could not fix this without a major reworking of valgrind! I tried to reproduce this optimization by modifying the calculation in the code but it didn't make a difference. I suspect that the compiler is undoing the change as part of optimization. So I forced my computer to do it by changing this: value & ~vbits to: vbits_xor(vbits_and(value, vbits), value); and putting those files into separate compilations units, in files by themselves. This forces the code to run the instructions exactly as I specify. I definitely wouldn't suggest doing this long term but, for testing purposes, you can try it out. I have attached a patch that you can try. I've added new files so don't forget to run autogen.sh and configure again.) Now when I run this: make -j 20 check && valgrind -q --expensive-definedness-checks=yes memcheck/tests/vbit-test/vbit-test I get this every time: ==586817== Conditional jump or move depends on uninitialised value(s) ==586817==at 0x110D4E: check_result_for_binary (binary.c:372) ==586817==by 0x1126B7: test_binary_op (binary.c:683) ==586817==by 0x110374: main (main.c:192) ==586817== Either of the patches that I have attached solve the problem so I feel confident that this will fix Andreas' problem. I much prefer the 3 line solution to the other one so I will deprecate that other solution. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #9 from Eyal --- Created attachment 162619 --> https://bugs.kde.org/attachment.cgi?id=162619&action=edit A test case to force this error even on amd64. This is just for testing purposes. Don't put this into the repo. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #10 from Eyal --- Comment on attachment 162608 --> https://bugs.kde.org/attachment.cgi?id=162608 This might fix it, too, but I prefer the other one. This one is much more convoluted and unnecessary. Just use the other one. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #11 from Eyal --- Comment on attachment 162608 --> https://bugs.kde.org/attachment.cgi?id=162608 This might fix it, too, but I prefer the other one. This one is bigger and the other one works just as well so don't use this one. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 --- Comment #13 from Eyal --- > I think my only question is whether we should "clear" all of data or just > the value fields of the result and opnds[] of the test_data_t? > I guess it doesn't matter whether the rest of the test_data_t struct values > are cleared too, but it might "hide" other/real bugs? I agree. Let's clear just the vbits in the values in a loop. I didn't know about the macro VALGRIND_MAKE_MEM_DEFINED so I'll use that one. I see that print_opnd is called sometimes before vbits get cleared by my new code so the clearing of vbits in print_opnd must remain in addition to this new one. I'll attach the new patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417993] vbit-test fail on s390x with Iop_Add32: spurious dependency on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=417993 Eyal changed: What|Removed |Added Attachment #162607|0 |1 is obsolete|| Attachment #162608|0 |1 is obsolete|| --- Comment #14 from Eyal --- Created attachment 162732 --> https://bugs.kde.org/attachment.cgi?id=162732&action=edit Clear just the vbits of the values of the operands after the test is done. This fixes the problem as tested by the test case patch on amd64_x86 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472878] New: Grouping: add toolbar buttons / actions
https://bugs.kde.org/show_bug.cgi?id=472878 Bug ID: 472878 Summary: Grouping: add toolbar buttons / actions Classification: Applications Product: digikam Version: unspecified Platform: Archlinux OS: All Status: REPORTED Severity: normal Priority: NOR Component: Albums-ItemGroup Assignee: digikam-bugs-n...@kde.org Reporter: e...@zvi.org Target Milestone: --- When selecting multiple images for grouping, the only way to group them is by right-clicking one of the images (the one that should be "on top"), then select from the menu Group, then select one of the Group actions. Toolbar buttons for the various grouping actions will make this much easier. It will also enable grouping while in Preview mode, which currently does not support a right-click menu. I suggest the following buttons: * Group selected. * Auto-group selected - opens a drop-down with the various automatic grouping methods. * Ungroup selected. * Remove selected from groups. * Show/Hide group - toggle (so no need for two buttons). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472879] New: Grouping: add Group to main Items menu
https://bugs.kde.org/show_bug.cgi?id=472879 Bug ID: 472879 Summary: Grouping: add Group to main Items menu Classification: Applications Product: digikam Version: unspecified Platform: Archlinux OS: All Status: REPORTED Severity: normal Priority: NOR Component: Albums-ItemGroup Assignee: digikam-bugs-n...@kde.org Reporter: e...@zvi.org Target Milestone: --- The main Item menu is missing grouping options. Usually the main menu of an application provides access to all major features. Grouping is certainly a major feature, and currently it's only accessible in the right-clock menu when in Icon-view. One particular need for having the Group sub-menu accessible from the main menu, is when in Preview mode, which currently lacks a right-click menu. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] New: Grouping: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 Bug ID: 472881 Summary: Grouping: add grouping by filename with versioning Classification: Applications Product: digikam Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-ItemGroup Assignee: digikam-bugs-n...@kde.org Reporter: e...@zvi.org Target Milestone: --- Digikam supports versioning. The Image Editor and Batch Manager support automatically saving modified images as a version of the original. However there is no automatic method to group image versions. If, for example, many images are processed in a Batch, they need to be grouped manually one by one. I suggest to add "Group Selected by Filename and Version" (under the Groups sub-menu). This action will match filenames but considering only the part of the filename before "_v*". (Note: I understand some users may have different version naming conventions, which do not necessarily use _v1 _v2 etc, and they will require different handling, maybe "Groups Selected by RegEx". However this bug refers specifically to support the standard versioning scheme used by Digikam.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 Eyal changed: What|Removed |Added Summary|Grouping: add grouping by |Grouping/Versioning: add |filename with versioning|grouping by filename with ||versioning -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472883] New: Grouping/Versioning: add Image Editor option to automatically group new version with original
https://bugs.kde.org/show_bug.cgi?id=472883 Bug ID: 472883 Summary: Grouping/Versioning: add Image Editor option to automatically group new version with original Classification: Applications Product: digikam Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ImageEditor-Versioning Assignee: digikam-bugs-n...@kde.org Reporter: e...@zvi.org Target Milestone: --- Image Editor supports automatically saving a modified image as a versions of the original. I suggest adding an option to automatically group the versioned image with the original. For users who group their image versions this is a very useful feature. The option should be added as a checkbox in the main configuration UI / Image Editor / Versioning. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 Eyal changed: What|Removed |Added Platform|Other |Archlinux -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472883] Grouping/Versioning: add Image Editor option to automatically group new version with original
https://bugs.kde.org/show_bug.cgi?id=472883 Eyal changed: What|Removed |Added Platform|Other |Archlinux -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472884] New: Grouping/Versioning: add Batch Queue Manager option to automatically group new version with original
https://bugs.kde.org/show_bug.cgi?id=472884 Bug ID: 472884 Summary: Grouping/Versioning: add Batch Queue Manager option to automatically group new version with original Classification: Applications Product: digikam Version: unspecified Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: BatchQueueManager-Core Assignee: digikam-bugs-n...@kde.org Reporter: e...@zvi.org Target Milestone: --- Batch Queue Manager supports automatically saving a modified image as a versions of the original (Queue Settings / Behavior / Save image as a newly created branch). I suggest adding an option to automatically group the versioned image with the original. For users who group their image versions this is a very useful feature, especially when batch processing large number of images. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #2 from Eyal --- I understand that technically my suggestion is a private case of a more generic / RegEx grouping. However, from a user perspective, grouping by Digikam's standard versioning scheme is less error prone than RegEx, priovides a more complete versioning solution, and will probably address the needs of the vast majority of users. Also, from a development point of view, it should simpler to add grouping by standard versioning. As RegEx can have very unexpected results (for non-experts), sooner or later RegEx grouping will require a complex UI which simulates the results before applying them, and "Undo last grouping". So I kindly ask that you keep my suggestion separate from RegEx grouping. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423993] Allow rightclick on thumbnails in preview mode
https://bugs.kde.org/show_bug.cgi?id=423993 Eyal changed: What|Removed |Added CC||e...@zvi.org --- Comment #7 from Eyal --- I strongly support right-click menu on the Preview strip. For example: While in Preview I edit an image with Image Editor. I save the result as a new version. I want to group the original and the new version. However as there's no right-click menu, I have to switch out of Preview, do the grouping and then switch back to Preview to continue my workflow. Why not do the grouping (or whatever else) directly in Preview? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #4 from Eyal --- So the fix for bug 318357 will also group these? filename.raw filename_v1.jpg filename_v2.jpg -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472883] Grouping/Versioning: add Image Editor option to automatically group new version with original
https://bugs.kde.org/show_bug.cgi?id=472883 --- Comment #2 from Eyal --- Only need to implement grouping function once, and call it from relevant tools. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472884] Grouping/Versioning: add Batch Queue Manager option to automatically group new version with original
https://bugs.kde.org/show_bug.cgi?id=472884 --- Comment #2 from Eyal --- Only need to implement grouping function once, and call it from relevant tools. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #6 from Eyal --- So why is this a duplicate of the other bug? I still wish to file a bug to have grouping that supports Digikam's versioning scheme. As it is, I can't file this bug because you mark it as a duplicate of another bug, which is apparently fixed but the fix doesn't really apply to my bug... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #8 from Eyal --- But I asked if the fix for bug 318357 will handle filename_v1, filename_v2, etc. - you answered it will not. I'm a bit confused. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #10 from Eyal --- Bug 338882 - is mostly ignored from 2014, and it is about *automatic* grouping (ie. no user intervention). Bug 318357 - I still don't understand if it covers the Digikam's own versioning. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 472881] Grouping/Versioning: add grouping by filename with versioning
https://bugs.kde.org/show_bug.cgi?id=472881 --- Comment #12 from Eyal --- I think it should be standalone. Regarding priority it's of course your decision. I can only ask you to consider this: Digikam has versioning. Digikam has grouping. But the two features don't work together. If I batch process thousands of photos which creates thousands of image pairs, I have no way to group them except manually one by one. So I only ask that grouping support Digikam's own versioning scheme. Not "every grouping problem", not support versioning scheme of other tools. In any case, thank you for the attention and patience. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 462443] New: Crash when renaming a file
https://bugs.kde.org/show_bug.cgi?id=462443 Bug ID: 462443 Summary: Crash when renaming a file Classification: Applications Product: dolphin Version: 22.08.3 Platform: Archlinux OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: e...@zvi.org CC: kfm-de...@kde.org Target Milestone: --- Application: dolphin (22.08.3) Qt Version: 5.15.7 Frameworks Version: 5.100.0 Operating System: Linux 6.0.10-arch2-1 x86_64 Windowing System: X11 Distribution: "Arch Linux" DrKonqi: 5.26.4 [KCrashBackend] -- Information about the crash: When renaming a file and pressing Enter, the file is renamed but Dolphin closes (crashes) immediately. The crash can be reproduced every time. -- Backtrace: Application: Dolphin (dolphin), signal: Segmentation fault [KCrash Handler] #4 0x7f9c34caebb7 in QObjectPrivate::ConnectionData::removeConnection(QObjectPrivate::Connection*) () from /usr/lib/libQt5Core.so.5 #5 0x7f9c34cb4606 in QObject::~QObject() () from /usr/lib/libQt5Core.so.5 #6 0x7f9c35aa111e in QLabel::~QLabel() () from /usr/lib/libQt5Widgets.so.5 #7 0x7f9c34cb3bd5 in QObjectPrivate::deleteChildren() () from /usr/lib/libQt5Core.so.5 #8 0x7f9c3599bd75 in QWidget::~QWidget() () from /usr/lib/libQt5Widgets.so.5 #9 0x7f9c36973c6a in ?? () from /usr/lib/libKF5BalooWidgets.so.5 #10 0x7f9c34cb0a0a in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #11 0x7f9c35978b1c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #12 0x7f9c34c8cf98 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #13 0x7f9c34c8daa3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #14 0x7f9c34cd3e68 in ?? () from /usr/lib/libQt5Core.so.5 #15 0x7f9c32b1687b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #16 0x7f9c32b6d299 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0x7f9c32b15132 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #18 0x7f9c34cd7c4c in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5 #19 0x7f9c34c8573c in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5 #20 0x7f9c34c90269 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #21 0x55cf5f897ca9 in ?? () #22 0x7f9c3443c290 in ?? () from /usr/lib/libc.so.6 #23 0x7f9c3443c34a in __libc_start_main () from /usr/lib/libc.so.6 #24 0x55cf5f8983f5 in ?? () [Inferior 1 (process 12849) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #37 from Eyal --- Any further comments? This is fixing a real false positive that users of clang will experience with reasonable optimization levels. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #138226|0 |1 is obsolete|| --- Comment #40 from Eyal --- Created attachment 139036 --> https://bugs.kde.org/attachment.cgi?id=139036&action=edit c++ patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates filter allocs for FreeBSD -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #41 from Eyal --- Got it done! Thank you for testing out the code. Try again? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #136599|0 |1 is obsolete|| --- Comment #31 from Eyal --- Created attachment 137990 --> https://bugs.kde.org/attachment.cgi?id=137990&action=edit c++ patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates This one compiles with both g++ and clang++, no warnings, no errors, passes tests in both cases -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #32 from Eyal --- How does the latest code look? Are all the warnings gone now? Passes tests on FreeBSD? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #34 from Eyal --- Huh. I don't have any errors on my computer with it. Can you send an example error from the test? Maybe the location of the conditional jump depends on the platform...? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Eyal changed: What|Removed |Added Attachment #137990|0 |1 is obsolete|| --- Comment #35 from Eyal --- Created attachment 138226 --> https://bugs.kde.org/attachment.cgi?id=138226&action=edit c++ patch that supports pcmpgtX for 64/32/16/8 bit testing all lanes and using templates -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 --- Comment #36 from Eyal --- Oh, I see it now. I must have forgotten to recompile. I've sent the new patch. -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 391422] New: Need to be able to search only non-commented code
https://bugs.kde.org/show_bug.cgi?id=391422
Bug ID: 391422
Summary: Need to be able to search only non-commented code
Product: kile
Version: 2.1.3
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: editor
Assignee: michel.lud...@kdemail.net
Reporter: eyal...@technion.ac.il
Target Milestone: ---
Kile is able to distinguish code (and text) that's commented, whether with a
percentage sign or within a {comment} environment. This functionality should
also be usable when searching, to avoid matches which are commented - if the
user has marked a checkbox saying s/he wants this.
This is related to bug 377334 (Ignore folded fragments of code when doing
search), but I believe should be of higher priority.
--
You are receiving this mail because:
You are watching all bug changes.
[kile] [Bug 391422] Need to be able to search only non-commented code
https://bugs.kde.org/show_bug.cgi?id=391422 Eyal Rozenberg changed: What|Removed |Added OS|Linux |All -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 392247] New: Structure tree construction does not ignore sectioning within comment environment
https://bugs.kde.org/show_bug.cgi?id=392247
Bug ID: 392247
Summary: Structure tree construction does not ignore sectioning
within comment environment
Product: kile
Version: unspecified
Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: michel.lud...@kdemail.net
Reporter: eyal...@technion.ac.il
Target Milestone: ---
I'm using Kile 2.1.3 (on Mint 18.3).
After everything else in my document (report class), I have the following code:
\begin{comment}
\appendix
\chapter*{Appendix}
\section*{Frobnicate the bar}
Bunch of text here, etc. etc.
\endcomment}
... and this shows up as part of the document structure tree, which it really
shouldn't - especially seeing how the comment environment is identified and its
contents is grayed-out.
This bug seems very related to bug 63121, which was about line comments (text
after the % symbol). However, that one was resolved 15 years ago. In fact, if I
add line comments within the comment environment, the appendix and the section
disappear from the structure tree; so it really looks like they're treated like
a normal part of the document.
--
You are receiving this mail because:
You are watching all bug changes.
[kile] [Bug 403804] New: RequesT: Support KDE Framework v5.28, not just 5.31
https://bugs.kde.org/show_bug.cgi?id=403804 Bug ID: 403804 Summary: RequesT: Support KDE Framework v5.28, not just 5.31 Product: kile Version: 2.9.92 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: michel.lud...@kdemail.net Reporter: eyal...@technion.ac.il Target Milestone: --- I'm trying to build Kile 3.0b2 (2.9.92) on a Devuan ASCII machine (it's essentially Debian Stretch). Now, Debian Stretch has version 5.28 of the KDE Framework, while KIle needs v5.31. I don't know what the exact differences are, but - if possible, can you get 2.9.92 to build with the prerequisites available on Debian? -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 403804] RequesT: Support KDE Framework v5.28, not just 5.31
https://bugs.kde.org/show_bug.cgi?id=403804 --- Comment #2 from Eyal Rozenberg --- (In reply to Michel Ludwig from comment #1) > Besides, frameworks 5.28 is already more than two years old. Stable distributions have a lot of code that is more than two years old; specifically, Debian. But - suit yourself. -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409836] New: Build failure: Undefined reference to setMountPointManager(MountPointManager*)
https://bugs.kde.org/show_bug.cgi?id=409836 Bug ID: 409836 Summary: Build failure: Undefined reference to setMountPointManager(MountPointManager*) Product: amarok Version: 2.9.0 Platform: Debian testing OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: amarok-bugs-d...@kde.org Reporter: eyal...@technion.ac.il Target Milestone: kf5 SUMMARY I'm building v2.9.0 on Debian buster (well, actually, Devuan Beowulf, which is the same thing but with systemd yanked out). CMake'ing works, and compilation goes fine. But during linking, I get the following: /usr/bin/ld: CMakeFiles/testsqltrack.dir/TestSqlTrack.cpp.o: in function `TestSqlTrack::initTestCase()': /usr/local/src/amarok-2.9.0/tests/core-impl/collections/db/sql/TestSqlTrack.cpp:52: undefined reference to `Collections::DatabaseCollection::setMountPointManager(MountPointManager*)' collect2: error: ld returned 1 exit status make[2]: *** [tests/core-impl/collections/db/sql/CMakeFiles/testsqltrack.dir/build.make:136: tests/testsqltrack] Error 1 make[1]: *** [CMakeFiles/Makefile2:3603: tests/core-impl/collections/db/sql/CMakeFiles/testsqltrack.dir/all] Error 2 and the same for a a few other targets. STEPS TO REPRODUCE 1. Install all relevant Debian packages for Amarok feature prerequisites 2. Run CMake on the v2.9.0 sources (downloaded today, 2019-07-14), with an out-of-source build directory 3. build SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux KDE Plasma Version: 5.54.0-1 KDE Frameworks Version: Not sure what number to put here. Qt Version: 5.11.3+dfsg1-1 ADDITIONAL INFORMATION Devuan Beowulf with no custom-built packages. -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409837] New: CMakeLists.txt doesn't check for presence of Embedded MariaDB
https://bugs.kde.org/show_bug.cgi?id=409837 Bug ID: 409837 Summary: CMakeLists.txt doesn't check for presence of Embedded MariaDB Product: amarok Version: 2.9.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: amarok-bugs-d...@kde.org Reporter: eyal...@technion.ac.il Target Milestone: kf5 SUMMARY I'm building v2.9.0 on Debian buster (well, actually, Devuan Beowulf, which is the same thing but with systemd yanked out). CMake'ing works, but during linking, I get this error: [ 61%] Linking CXX shared module ../../../../../lib/amarok_storage-mysqlestorage.so /usr/bin/ld: cannot find -lmariadbd collect2: error: ld returned 1 exit status indeed, I didn't have embedded MariaDB installed. When I installed the package for it, the error went away. So, CMake should have checked for this library's presence - and didn't; or alternatively, mistakenly thought it had located it. -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409836] Build failure: Undefined reference to setMountPointManager(MountPointManager*)
https://bugs.kde.org/show_bug.cgi?id=409836 Eyal Rozenberg changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Eyal Rozenberg --- (In reply to Myriam Schweingruber from comment #1) > Did you try building with testing disabled? No, I used the default options. With testing disabled, the build concludes without errors. -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409836] Build failure: Undefined reference to setMountPointManager(MountPointManager*)
https://bugs.kde.org/show_bug.cgi?id=409836 --- Comment #4 from Eyal Rozenberg --- (In reply to Myriam Schweingruber from comment #3) > I guessed as much. It's still a build failure, albeit of the testing code. Aren't you supposed to change the component or mark it somehow instead of testing it? -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409966] New: Amarok won't run, complains about missing plugins
https://bugs.kde.org/show_bug.cgi?id=409966 Bug ID: 409966 Summary: Amarok won't run, complains about missing plugins Product: amarok Version: 2.9.0 Platform: Debian testing OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: amarok-bugs-d...@kde.org Reporter: eyal...@technion.ac.il Target Milestone: kf5 I've downloaded and built Amarok 2.9.0 on Devuan Beowulf (= Debian Buster without systemd) - after installing a whole bunch of prerequisite Qt and KDE-related packaged. The build succeeds (after a bit of trouble I reported in other issues and got resolved); and I make install'ed amarok to /usr/loca . Now, when trying to run amarok, I get ``` amarok(24045)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType "Amarok/Plugin" not found ``` on the console, and a message box saying: > Amarok could not find any plugins. This indicates an installation problem. I'm reporting this as a bug for several reasons: 1. If something else need to be present on the system, then cmake'ing should have told me so. 2. Even if something is missing, the GUI and/or console messages should tell me what exactly what files, or folders, are missing so that I could go get them. 3. If plugins need to be installed independently - why aren't they available on the website? 4. If plugins are built and installed - how come amarok doesn't make even a minimal effort to locate them? Note: This is not resolved like the very similar problem I reported a while ago as the very similar bug 399097. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux KDE Plasma Version: 5.54.0-1 KDE Frameworks Version: Not sure what number to put here. Qt Version: 5.11.3+dfsg1-1 -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409966] Amarok won't run, complains about missing plugins
https://bugs.kde.org/show_bug.cgi?id=409966 Eyal Rozenberg changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|NOT A BUG |--- --- Comment #2 from Eyal Rozenberg --- (In reply to Christoph Feck from comment #1) > cmake is only a tool to _build_ the software. It's a tool to build the software so that it runs. > If you want to _run_ the > software, you should make sure you are installing it into directories where > the plugin loaders expect them, or adjust your environment variables > accordingly. I did make sure: I used -DCMAKE_INSTALL_PREFIX=/usr/local , which is perfectly valid and standard. I than used cmake to install. That installation should work. And if for some reason it can't (which shouldn't happen IMHO) - I should have been informed. I won't split hairs, so - I wouldn't have minded if it had been cmake install that gives some error or warning messages. > Please ask for help in a developer forum, mailing list, or IRC channel. But, again, I shouldn't need to: I did something very standard and straightfoward and the result was not as expected, without any warning/error messages up until installation. That _is_ a bug. Having said that - I did ask for help on the IRC channel, but none was extended. Which of the other two media would you suggest? -- You are receiving this mail because: You are watching all bug changes.
[extra-cmake-modules] [Bug 409966] Check if plugin install path is where the system expects them
https://bugs.kde.org/show_bug.cgi?id=409966 --- Comment #6 from Eyal Rozenberg --- (In reply to Christophe Giboudeaux from comment #4) > why ecm ? isn't amarok 2.9 the KDE4 version? Can you explain the latest exchange of comments? I'm not quite following. Amarok 2.9 is the current release version, is it not? -- You are receiving this mail because: You are watching all bug changes.
[extra-cmake-modules] [Bug 409966] Check if plugin install path is where the system expects them
https://bugs.kde.org/show_bug.cgi?id=409966 Eyal Rozenberg changed: What|Removed |Added Resolution|NOT A BUG |--- Status|RESOLVED|REOPENED --- Comment #8 from Eyal Rozenberg --- (In reply to Christophe Giboudeaux from comment #7) > I recommend looking for a music player which is still maintained. I double-checked to ensure I wasn't missing a version 2.10 or 3.0 - and no, I wasn't. So, either Amarok is not maintained, period - which would be pretty sad; or v2.9 is maintained, albeit perhaps reluctantly and partially. Also - I can't just use the GitHub master branch, it depends on much newer versions of various libraries than typical distributions have . -- You are receiving this mail because: You are watching all bug changes.
[extra-cmake-modules] [Bug 409966] Check if plugin install path is where the system expects them
https://bugs.kde.org/show_bug.cgi?id=409966 --- Comment #10 from Eyal Rozenberg --- (In reply to Christophe Giboudeaux from comment #9) > Doesn't change anything. There's no officially supported Qt5 based amarok The single current official release of Amarok is 2.9.0. That's the one with this issue. That's the one that must be supported. If it uses KDE4 - fine, then that's what it uses. If it has issues then - fix them. You can't just ignore them because you don't like how the official version uses KDE4. I simply don't understand what you're talking about. And reopen this bug. -- You are receiving this mail because: You are watching all bug changes.
[extra-cmake-modules] [Bug 409966] Check if plugin install path is where the system expects them
https://bugs.kde.org/show_bug.cgi?id=409966 --- Comment #12 from Eyal Rozenberg --- Excuse me, but - are you serious? This is the _Amarok_ bug tracking system. You can't close bugs about the current release and tell people not to use it. If that's how you feel - terminate your account or stop all activity on Amarok-related bugs. Are you trying to sabotage it or something? -- You are receiving this mail because: You are watching all bug changes.
[extra-cmake-modules] [Bug 409966] Check if plugin install path is where the system expects them
https://bugs.kde.org/show_bug.cgi?id=409966 --- Comment #14 from Eyal Rozenberg --- Ah, I see what you mean. Ok then. That is, I'm not pleased but at least I understand the rationale of your decisions. -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 409837] CMakeLists.txt doesn't check for presence of Embedded MariaDB
https://bugs.kde.org/show_bug.cgi?id=409837 --- Comment #2 from Eyal Rozenberg --- (In reply to Heiko Becker from comment #1) Which exact version should I try and build? -- You are receiving this mail because: You are watching all bug changes.
