[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 Tatyana changed: What|Removed |Added CC||tatyana.a.mine...@intel.com --- Comment #4 from Tatyana --- Created attachment 105595 --> https://bugs.kde.org/attachment.cgi?id=105595&action=edit Proposed patch Proposed a patch that implements the missing opcodes and allows them to have any prefixes or operands. -- You are receiving this mail because: You are watching all bug changes.
[KDE Linux] [Bug 504902] New: Digikam crashes when removing red eye (without loading additional files)
https://bugs.kde.org/show_bug.cgi?id=504902 Bug ID: 504902 Summary: Digikam crashes when removing red eye (without loading additional files) Classification: KDE Linux Product: KDE Linux Version First unspecified Reported In: Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: n...@kde.org Reporter: taty...@basealt.ru CC: n...@kde.org, sit...@kde.org Target Milestone: --- Created attachment 181810 --> https://bugs.kde.org/attachment.cgi?id=181810&action=edit video crashes STEPS TO REPRODUCE 1. Install: # apt-get install kde6-libksane-common digikam 2. Run: $ digikam 3. At the "Downloading required files" step, do not click "Get" -> Finish. 4. Import -> Add folders (select folder with image) -> select photo -> Image editor -> Enhance -> Red eye removal. OBSERVED RESULT Segmentation fault (memory image flushed to disk) EXPECTED RESULT digikam works without falls SOFTWARE/OS VERSIONS Linux/KDE Plasma: ALT Workstation K 11.0 KDE Frameworks Version: 6.14.0 Qt Version: 6.8.2 Kernel: 6.12.30-6.12-alt2 digikam-8.6.0-alt1 ADDITIONAL INFORMATION Crash after switching to the editor to disable the red eye effect. Workaround: on first launch click Next (on all steps) -> Finish -> on the step "Loading necessary files" click "Get" -> wait for loading -> OK -> restart digikam. On earlier versions (for example, in digikam-8.5.0-alt2) this step № 3 was not required, it worked stably without additional file loading. Now only with loading additional files (see the step "Loading necessary files" at the first launch) -- You are receiving this mail because: You are watching all bug changes.
[KDE Linux] [Bug 504902] Digikam crashes when removing red eye (without loading additional files)
https://bugs.kde.org/show_bug.cgi?id=504902 --- Comment #1 from tatyana --- Created attachment 181811 --> https://bugs.kde.org/attachment.cgi?id=181811&action=edit backtrace backtrace -- You are receiving this mail because: You are watching all bug changes.
[KDE Linux] [Bug 504902] Digikam crashes when removing red eye (without loading additional files)
https://bugs.kde.org/show_bug.cgi?id=504902 --- Comment #2 from tatyana --- Created attachment 181812 --> https://bugs.kde.org/attachment.cgi?id=181812&action=edit albom (photo) -- You are receiving this mail because: You are watching all bug changes.
[Tokodon] [Bug 504946] New: The tokodon does not attach file and a survey when creating a publication
https://bugs.kde.org/show_bug.cgi?id=504946 Bug ID: 504946 Summary: The tokodon does not attach file and a survey when creating a publication Classification: Applications Product: Tokodon Version First 25.04.1 Reported In: Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: taty...@basealt.ru CC: c...@carlschwan.eu, j...@redstrate.com Target Milestone: --- Created attachment 181844 --> https://bugs.kde.org/attachment.cgi?id=181844&action=edit the survey is already attached STEPS TO REPRODUCE 1. Install: # apt-get install tokodon 2. Run: $ tokodon 3. Login to your account 4. Create a "+Publication" post -> click on the "Attach file" paperclip -> click on the "Attach poll". EXPECTED RESULT The file and the survey are attached when creating a single entry. OBSERVED RESULT It is not possible to attach a survey and a file to a publication at the same time. SOFTWARE/OS VERSIONS Linux/KDE Plasma: ALT Workstation K 11.0 KDE Frameworks Version: 6.14.0 Qt Version: 6.8.2 Kernel: 6.12.30-6.12-alt2 -- You are receiving this mail because: You are watching all bug changes.
[Tokodon] [Bug 504946] The tokodon does not attach file and a survey when creating a publication
https://bugs.kde.org/show_bug.cgi?id=504946 --- Comment #1 from tatyana --- Created attachment 181845 --> https://bugs.kde.org/attachment.cgi?id=181845&action=edit the file is already attached -- You are receiving this mail because: You are watching all bug changes.
[Tokodon] [Bug 504946] The tokodon does not attach file and a survey when creating a publication
https://bugs.kde.org/show_bug.cgi?id=504946 --- Comment #3 from tatyana --- (In reply to Joshua Goins from comment #2) > This is intentional, Mastodon does not support showing both at once so it's > just not allowed. Thanks for the answer! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 504902] Digikam crashes when removing red eye (without loading additional files)
https://bugs.kde.org/show_bug.cgi?id=504902 --- Comment #6 from tatyana --- (In reply to Maik Qualmann from comment #5) > Git commit 3ba1343ec49523f604fd6820c3870e6adcd5dbb6 by Maik Qualmann. > Committed on 29/05/2025 at 05:06. > Pushed by mqualmann into branch 'master'. > > fix red eye correction when no face models are loaded > FIXED-IN: 8.7.0 > > M +1-1NEWS > M +8-1core/libs/dimg/filters/redeye/redeyecorrectionfilter.cpp > > https://invent.kde.org/graphics/digikam/-/commit/ > 3ba1343ec49523f604fd6820c3870e6adcd5dbb6 Thank you for your work! -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 364738] Snap packages install but fail to launch
https://bugs.kde.org/show_bug.cgi?id=364738 Tatyana changed: What|Removed |Added CC||taty...@express.newalive.or ||g -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357010] New: drd regression tests fail to compile with Intel compiler
https://bugs.kde.org/show_bug.cgi?id=357010 Bug ID: 357010 Summary: drd regression tests fail to compile with Intel compiler Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: drd Assignee: bvanass...@acm.org Reporter: tatyana.a.mine...@intel.com File drd/tests/std_string.cpp fails to compile with Intel compiler (versions 15.0.3, 16.0.0) Reproducible: Always Steps to Reproduce: 1. Configure Valgrind to be built with Intel compiler 2. Build regression tests (make regtest) Actual Results: File drd/tests/std_string.cpp fails to compile Expected Results: Regression tests are built and run The reason is a known bug of Intel compiler. If gcc 5.2.0 headers are used, in certain cases integers are misinterpreted as iterators: https://software.intel.com/en-us/forums/intel-c-compiler/topic/565143 . The compiler bug has high priority, but it is difficult to fix. The workaround is to change argument type from integer to double for Intel compilation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357010] drd regression tests fail to compile with Intel compiler
https://bugs.kde.org/show_bug.cgi?id=357010 Tatyana changed: What|Removed |Added CC||tatyana.a.mine...@intel.com --- Comment #1 from Tatyana --- Created attachment 96238 --> https://bugs.kde.org/attachment.cgi?id=96238&action=edit Proposed workaround -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357010] drd regression tests fail to compile with Intel compiler
https://bugs.kde.org/show_bug.cgi?id=357010
--- Comment #2 from Tatyana ---
Comment on attachment 96238
--> https://bugs.kde.org/attachment.cgi?id=96238
Proposed workaround
>--- valgrind-3.11.0/drd/tests/std_string.cpp 2015-09-08 16:23:31.0
>+0300
>+++ valgrind-3.11.0/drd/tests/std_string.cpp 2015-12-15 21:47:14.114795475
>+0300
>@@ -35,7 +35,13 @@
> {
> for (int i = 0; i < 100; i++) {
> std::string id("000");
>+#ifdef __INTEL_COMPILER
>+// Intel compiler (version 15.0.3 - 16.0.0) fails to compile the following
>line due to a compiler bug
>+// A known workaround is to use double instead of int
>+id.append(1.0, 'a' + i);
>+#else
> id.append(1, 'a' + i);
>+#endif
> std::list record;
> record.push_back("some data");
> addRecord();
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 357011] New: Memcheck regression tests do not generate expected frame numbers if compiled with intel compiler
https://bugs.kde.org/show_bug.cgi?id=357011 Bug ID: 357011 Summary: Memcheck regression tests do not generate expected frame numbers if compiled with intel compiler Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96239 --> https://bugs.kde.org/attachment.cgi?id=96239&action=edit Proposed patch Frame numbers are compiler-dependent, and they do not match for gcc-compiled and intel-compiled regression tests. Frame numbers are filtered in the helgrind component. Would it be possible to filter frame numbers in memcheck component, too? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357012] New: Memcheck regression tests do not match expected results if compiled with intel compiler
https://bugs.kde.org/show_bug.cgi?id=357012 Bug ID: 357012 Summary: Memcheck regression tests do not match expected results if compiled with intel compiler Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96240 --> https://bugs.kde.org/attachment.cgi?id=96240&action=edit Proposed patch - Tests "varinfo3" and "varinfo5" use compiler-dependent variable names; these names are later filtered. Variable names, generated by Intel compiler, do not match the existing filter pattern. This patch updates the filter pattern in file "filter_varinfo3". - Reported line numbers differ from expected ones for intel-compiled test applications “insn-pcmpistri” and “insn-pmovmskb”. The reported line numbers are correct, so the patch adds alternative expected test results. - In intel-compiled test "memalign_test", function call stack is different from the expected one (due to compiler optimization). Adding an alternative expected test result. The differences between added .exp-icc files and corresponding .exp files are listed in memcheck_deltas.diff file. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357012] Memcheck regression tests do not match expected results if compiled with intel compiler
https://bugs.kde.org/show_bug.cgi?id=357012 --- Comment #1 from Tatyana --- Created attachment 96241 --> https://bugs.kde.org/attachment.cgi?id=96241&action=edit Differences between proposed .exp-icc files and corresponding .exp files -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357014] New: Helgrind regression tests do not match expected results if compiled with intel compiler
https://bugs.kde.org/show_bug.cgi?id=357014 Bug ID: 357014 Summary: Helgrind regression tests do not match expected results if compiled with intel compiler Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: helgrind Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96242 --> https://bugs.kde.org/attachment.cgi?id=96242&action=edit Proposed patch Several helgrind tests do not produce the expected results if Valgrind is compiled with Intel compiler. The reason is that expected results contain call stacks of helgrind functions. On Intel compilation, one of the functions in the call stack is optimized out (due to tail call elimination), so the call stack appears to be different. The proposed patch adds alternate expected test results with a modified call stack. The differences between added .exp-icc files and corresponding .exp files are listed in helgrind_deltas.diff file. One of Valgrind suppression rules relies on this call stack, too. The proposed patch adds a suppression rule that relies on the intel-specific call stack for Intel-compiled version of Valgrind. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357014] Helgrind regression tests do not match expected results if compiled with intel compiler
https://bugs.kde.org/show_bug.cgi?id=357014 --- Comment #1 from Tatyana --- Created attachment 96243 --> https://bugs.kde.org/attachment.cgi?id=96243&action=edit Differences between proposed .exp-icc files and corresponding .exp files -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357033] New: VALGRIND_DO_QUICK_LEAK_CHECK reports leaked and dubious memory as reachable in intel-compiled applications.
https://bugs.kde.org/show_bug.cgi?id=357033 Bug ID: 357033 Summary: VALGRIND_DO_QUICK_LEAK_CHECK reports leaked and dubious memory as reachable in intel-compiled applications. Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96255 --> https://bugs.kde.org/attachment.cgi?id=96255&action=edit a reproducer application If an application is built with Intel compiler, Valgrind client requests VALGRIND_DO_QUICK_LEAK_CHECK reports leaked and dubious memory as reachable. A reproducer (error_types.c) is attached. Steps to build and run the test: icc -I -O0 error_types.c -o error_types_icc valgrind -q ./error_types_icc Expected result (reported for the gcc-compiled application): leaked: 77 bytes dubious: 88 bytes reachable:0 bytes suppressed: 0 bytes Actual result: leaked: 0 bytes dubious: 0 bytes reachable: 165 bytes suppressed: 0 bytes -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357034] New: Inlined functions are not reported for intel-compiled applications.
https://bugs.kde.org/show_bug.cgi?id=357034 Bug ID: 357034 Summary: Inlined functions are not reported for intel-compiled applications. Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com If an application is built with Intel compiler, memcheck report does not contain inlined functions. A reproducer (inline_info.c) is attached. Steps to build and run the test: icc -O0 inline_info.c -g -o inline_info_icc valgrind -q --read-inline-info=yes ./inline_info_icc Expected result (reported for gcc-compiled application): ==== Conditional jump or move depends on uninitialised value(s) ====at 0xxx: inlined (inline_info.c:5) ====by 0xxx: main (inline_info.c:13) ==== Actual result: ==== Conditional jump or move depends on uninitialised value(s) ====at 0xxx: main (inline_info.c:5) ==== -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357034] Inlined functions are not reported for intel-compiled applications.
https://bugs.kde.org/show_bug.cgi?id=357034 --- Comment #1 from Tatyana --- Created attachment 96256 --> https://bugs.kde.org/attachment.cgi?id=96256&action=edit a reproducer application -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357035] New: Uninitialized variable of type double is reported twice in intel-compiled application.
https://bugs.kde.org/show_bug.cgi?id=357035 Bug ID: 357035 Summary: Uninitialized variable of type double is reported twice in intel-compiled application. Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96257 --> https://bugs.kde.org/attachment.cgi?id=96257&action=edit a reproducer application If an application is built with intel compiler, memcheck reports uninitialized variables of type double twice. Steps to build and run the test: icc -O0 double_report.c -o double_report_icc valgrind -q ./double_report_icc A reproducer (double_report.c) is attached. Expected result (reported for gcc-compiled application): ==== Conditional jump or move depends on uninitialised value(s) ====at 0xxx: main (in //double_report_icc) ==== Actual result: ==== Conditional jump or move depends on uninitialised value(s) ====at 0xxx: main (in //double_report_icc) ==== ==== Conditional jump or move depends on uninitialised value(s) ====at 0xxx: main (in //double_report_icc) ==== -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357037] New: Line numbers are occasionally displayed incorrectly in intel-compiled applications
https://bugs.kde.org/show_bug.cgi?id=357037 Bug ID: 357037 Summary: Line numbers are occasionally displayed incorrectly in intel-compiled applications Product: valgrind Version: 3.10 SVN Platform: RedHat RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: tatyana.a.mine...@intel.com Created attachment 96260 --> https://bugs.kde.org/attachment.cgi?id=96260&action=edit a reproducer application If an application is compiled with Intel compiler, line numbers are displayed incorrectly if the line contains line break. A reproducer application (line_numbers.c) is attached. Steps to build and run the test: icc -O0 -g line_numbers.c -o line_numbers_icc valgrind -q ./line_numbers_icc Expected result (reported for gcc-compiled application): ==== Invalid write of size 4 ====at 0xxx: main (line_numbers.c:8) ==== Address 0 is 4 bytes inside a block of size 40 free'd ====at 0: free (vg_replace_malloc.c:530) ====by 0xxx: main (line_numbers.c:7) ==== Block was alloc'd at ====at 0: malloc (vg_replace_malloc.c:299) ====by 0xxx: main (line_numbers.c:5) ==== Actual result: ==== Invalid write of size 4 ====at 0xxx: main (line_numbers.c:8) ==== Address 0 is 4 bytes inside a block of size 40 free'd ====at 0: free (vg_replace_malloc.c:530) ====by 0xxx: main (line_numbers.c:7) ==== Block was alloc'd at ====at 0: malloc (vg_replace_malloc.c:299) ====by 0xxx: main (line_numbers.c:7) ==== -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357035] Uninitialized variable of type double is reported twice in intel-compiled application.
https://bugs.kde.org/show_bug.cgi?id=357035 --- Comment #2 from Tatyana --- Tom Hughes, yes, you are correct, the variable is actually read twice. Please feel free to close/discard the ticket. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357033] VALGRIND_DO_QUICK_LEAK_CHECK reports leaked and dubious memory as reachable in intel-compiled applications.
https://bugs.kde.org/show_bug.cgi?id=357033 Tatyana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Tatyana --- Hello Philippe, Thank you very much for the link. You are correct, the cause is that intel compiler leaves copies of pointers on registers. Thank you for pointing on leak-cases.c; I'll check if it is possible to limit this behaviour in the regression tests. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357034] Inlined functions are not reported for intel-compiled applications.
https://bugs.kde.org/show_bug.cgi?id=357034 Tatyana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Tatyana --- Hello Philippe, Thank you for the clarification. Apparently, Intel compiler does not generate full inline information by default (full inline info can be generated using "-debug inline_debug_info" compilation flag). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357037] Line numbers are occasionally displayed incorrectly in intel-compiled applications
https://bugs.kde.org/show_bug.cgi?id=357037 Tatyana changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tatyana --- (In reply to Philippe Waroquiers from comment #1) > It would be good to analyse the debug info generated by icc > e.g. using objdump > and/or using gdb e.g. info line 5/6/7 > and info line *0x.. > and/or the valgrind gdbserver monitor command v.info location >(where addr is an address that should be part of the line 5) Philippe Waroquiers, Thank you very much. The debug information is generated incorrectly by compiler. -- You are receiving this mail because: You are watching all bug changes.
