[valgrind] [Bug 196335] valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.

2023-02-21 Thread Thorsten Glaser
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

2017-03-20 Thread Thorsten Glaser
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

T

[kmail2] [Bug 248058] Message preview pane character encoding issue (utf-8, unicode)

2016-06-27 Thread Thorsten Glaser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=248058

--- Comment #12 from Thorsten Glaser  ---
(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)

2016-06-24 Thread Thorsten Glaser via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=248058

--- Comment #8 from Thorsten Glaser  ---
(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.