[valgrind] [Bug 196335] valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
https://bugs.kde.org/show_bug.cgi?id=196335 Thorsten Glaser changed: What|Removed |Added CC||t.gla...@tarent.de Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|WAITINGFORINFO |--- --- Comment #9 from Thorsten Glaser --- A colleage could reproduce this bug today: I have no name!@9019b147885f:/code$ valgrind --track-origins=yes pytest valgrind: m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed. Segmentation fault (core dumped) This is a Debian bookworm Docker image under Arch Linux; even “valgrind false” fails like this. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 377832] New: Kontact crashes often, e.g. when going to Settings → Configure Kontact
https://bugs.kde.org/show_bug.cgi?id=377832 Bug ID: 377832 Summary: Kontact crashes often, e.g. when going to Settings → Configure Kontact Product: kontact Version: 5.2.3 Platform: Debian stable OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: t.gla...@tarent.de Target Milestone: --- Application: kontact (5.2.3) Qt Version: 5.7.1 Frameworks Version: 5.28.0 Operating System: Linux 4.9.0-2-amd64 x86_64 Distribution: Debian GNU/Linux 9.0 (stretch) -- Information about the crash: - What I was doing when the application crashed: I started Kontact and went to Settings → Configure Kontact, insta-Crash. It also occasionally crashes when doing, or not doing, much else, after a while. Operating system: Debian sid/x32 The crash can be reproduced every time. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1". [Current thread is 1 (Thread 0xded3a840 (LWP 12947))] Thread 21 (Thread 0xc06c3940 (LWP 12990)): #0 0xeef6c9fc in pthread_cond_wait@@GLIBC_2.16 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0xe2d1c614 in () at /usr/lib/x86_64-linux-gnux32/libQt5Script.so.5 #2 0xe2d1c658 in () at /usr/lib/x86_64-linux-gnux32/libQt5Script.so.5 #3 0xeef66cbc in start_thread (arg=) at pthread_create.c:333 #4 0xf4ae263f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 20 (Thread 0xc19ad940 (LWP 12976)): #0 0xf4ad9a8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0xed2107d5 in g_main_context_poll (priority=, n_fds=1, fds=0xd540e390, timeout=, context=0xd540b770) at ././glib/gmain.c:4228 #2 0xed2107d5 in g_main_context_iterate (context=context@entry=0xd540b770, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3924 #3 0xed2108eb in g_main_context_iteration (context=0xd540b770, may_block=1) at ././glib/gmain.c:3990 #4 0xf55c7803 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #5 0xf557132a in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #6 0xf539731f in QThread::exec() () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #7 0xf539be20 in () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #8 0xeef66cbc in start_thread (arg=) at pthread_create.c:333 #9 0xf4ae263f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 19 (Thread 0xc21ae940 (LWP 12974)): #0 0xffae2649 in () #1 0xffae28d9 in __vdso_clock_gettime () #2 0xf4aef433 in __GI___clock_gettime (clock_id=1, tp=) at ../sysdeps/unix/clock_gettime.c:115 #3 0xf54449ce in () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #4 0xf55c54b9 in QTimerInfoList::updateCurrentTime() () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #5 0xf55c5a74 in QTimerInfoList::timerWait(timespec&) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #6 0xf55c6e84 in () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #7 0xed20fbf9 in g_main_context_prepare (context=context@entry=0xd4e0b9d0, priority=priority@entry=0xc21ade94) at ././glib/gmain.c:3501 #8 0xed2106f2 in g_main_context_iterate (context=context@entry=0xd4e0b9d0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3909 #9 0xed2108eb in g_main_context_iteration (context=0xd4e0b9d0, may_block=1) at ././glib/gmain.c:3990 #10 0xf55c7803 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #11 0xf557132a in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #12 0xf539731f in QThread::exec() () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #13 0xf539be20 in () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #14 0xeef66cbc in start_thread (arg=) at pthread_create.c:333 #15 0xf4ae263f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 18 (Thread 0xc39ec940 (LWP 12972)): #0 0xed2554d0 in g_mutex_unlock (mutex=0x572e96e0) at ././glib/gthread-posix.c:1345 #1 0xed2106e6 in g_main_context_iterate (context=context@entry=0x572e96e0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3907 #2 0xed2108eb in g_main_context_iteration (context=0x572e96e0, may_block=1) at ././glib/gmain.c:3990 #3 0xf55c7803 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #4 0xf557132a in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #5 0xf539731f in QThread::exec() () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #6 0xf539be20 in () at /usr/lib/x86_64-linux-gnux32/libQt5Core.so.5 #7 0xeef66cbc in start_thread (arg=) at pthread_create.c:333 #8 0xf4ae263f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
[kmail2] [Bug 248058] Message preview pane character encoding issue (utf-8, unicode)
https://bugs.kde.org/show_bug.cgi?id=248058 --- Comment #12 from Thorsten Glaser <t.gla...@tarent.de> --- (In reply to Sandro Knauß from comment #9) > Make the experiment - change the charset of you konsole/ and use a text > document with a different encoding and encrypt it and look at the output in > your normal console ( utf-8). You will see that this is broken. This all > works for you because you have a consistent utf8 environment. But for mails Possibly, but ISTR that OpenPGP still stores the encoding of the message, so I’d have a way to know what charset to pass to iconv(1) to be able to read it, and I’m not talking about the ASCII armour pseudo-header either. I’ll search for it when I have more time. > > > GnuPG / GPGME itself does not do any reencoding it just decrypts the > > > "bytes" > > > of the message. > > > > It does *record* the charset of the message. > > But maybe all are wrong and you are right - give me the link to the > documentation or a script/snippset, how It detect the correct charset of the > decrypted mail i'll fix this instantly in kmail. OK. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 248058] Message preview pane character encoding issue (utf-8, unicode)
https://bugs.kde.org/show_bug.cgi?id=248058 --- Comment #8 from Thorsten Glaser <t.gla...@tarent.de> --- (In reply to Andre Heinecke from comment #7) > > PGP Inline is perfectly fine standardised: the display agent has to use the > > charset indicated by the PGP > > message, and discard any charset/encoding information of the surrounding > > message. > > No it's not. Especially the Encoding handling is very problematic and not > standardised. See: https://debian-administration.org/users/dkg/weblog/108 ( It is, and especially the encoding is trivial. It’s just often misunderstood or implemented wrong. Citing someone who doesn’t fully understand it doesn’t help (I knew that posting). Inline PGP is easy: the MIME-level encoding is valid for the “outer” part of the message; for example, if MIME says quoted-printable then those ‘=’ in the ASCII armour of the PGP message are encoded as “=3D”. The “inner” part of the message, i.e. the output of pgp/gpg decrypting it, is *completely* independent of the MIME message surrounding it, and for displaying it, *only* the rules that the command-line utilities use are valid; this means, that the OpenPGP-level encoding is used (which is always 8bit not quoted-printable or base64, and in absence of an explicit charset selection is UTF-8). The reason for this is easy: Inline PGP works, basically (i.e. without explicit MUA support), by someone writing a plaintext file, throwing that through pgp or gpg, and copy/pasting that into their MUA’s composer. Anything an MUA does to integrate Inline PGP support *must* behave *exactly the same*. > Basically your Mail says that it's ASCII Encoded but then actually has UTF-8 > encoding in the content after decryption. I would argue that this is not a See above, “after decryption” when Inline PGP is used means you *have* to *forget* anything from the previous container. Yes, this is different than what PGP/MIME requires. Yes, both are right, for their respective scopes. > KMail bug but that your Mail is broken. For proper encoding Handling you > need to use PGP/MIME. One of the Advantages of PGP/MIME is proper encoding This sounds half like a sales pitch, half like “KMail doesn’t handle encoding in Inline PGP correctly” – which is *exactly my point*. > GnuPG / GPGME itself does not do any reencoding it just decrypts the "bytes" > of the message. It does *record* the charset of the message. > As a "workaround" / to improve compatibility with broken MUA's I like > Sandro's idea to treat PGP Messages as UTF-8 if the specified Charset is > 7Bit ASCII. I think that would be a good solution to fix your bug. That would help in the specific case, but still leave KMail a broken MUA claiming to support Inline PGP and not doing it correctly. However, as a first step, it’s okay; please do so. Actually, why haven’t you done so yet… > Although I would suggest to use a proper MUA with PGP/MIME support. No, PGP/MIME often breaks, interestingly enough, with encoding-related issues, and with mailing lists. Its interoperability is also limited to MUAs supporting it, whereas interoperability of Inline PGP is maximal. -- You are receiving this mail because: You are watching all bug changes.
