[kmail2] [Bug 409344] New: KMail crashes when closing a message opened twice or more

[SasQ]

https://bugs.kde.org/show_bug.cgi?id=409344

Bug ID: 409344
   Summary: KMail crashes when closing a message opened twice or
more
   Product: kmail2
   Version: 5.9.3
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: crash
  Priority: NOR
 Component: composer
  Assignee: kdepim-b...@kde.org
  Reporter: s...@poczta.ox.pl
  Target Milestone: ---

SUMMARY
The entire program crashes when I open the same message more than once (by
double-clicking on in in the inbox).
I discovered this by accidentally opening more than one instance of the same
message because my mouse is broken and sometimes it gets "autofire" :J

STEPS TO REPRODUCE
1. Double-click on a message in the inbox to open it.
2. Open the same message again in the same way.
3. Close one of those editor windows.

OBSERVED RESULT
The entire program crashes.
I can reproduce it every time.

EXPECTED RESULT
No crash, obviously :q

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux 4.14.65-gentoo
KDE Plasma Version: kde-frameworks/plasma-5.54.0:5/5.54::gentoo
KDE Frameworks Version: No clue. Where can I find it?
Qt Version: dev-qt/qtcore-5.11.3-r2:5/5.11::gentoo

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[okteta] [Bug 396057] New: Pascal-style RLE strings not working properly for length 1, both JS and OSD

[SasQ]

https://bugs.kde.org/show_bug.cgi?id=396057

Bug ID: 396057
   Summary: Pascal-style RLE strings not working properly for
length 1, both JS and OSD
   Product: okteta
   Version: unspecified
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Structures Tool
  Assignee: arichardson@gmail.com
  Reporter: sa...@o2.pl
CC: kosse...@kde.org
  Target Milestone: ---

The following simple test structure definition for recognizing Pascal-style
(run length ncoded) strings works only for strings longer than 1 byte, but for
lengths 1 and 0 shows that the string has length 0 while still containing the
previous content (sometimes with garbage characters at the beginning):

function init() {
var obj = struct({
len: uint16(),
data: string("utf-8")
});
obj.byteOrder = "big-endian";
obj.child("data").updateFunc = function() {
this.maxByteCount = this.parent.len.value;
};
return obj;
}

Or the same expressed in the XML format:









Here's a sample data I select:

00 04 41 42 43 44 45 46 47 48|..ABCDEFGH|

In this case, it correctly contains only a 4-byte string, "ABCD" (4).
But when I change the data to this:

00 01 41 42 43 44 45 46 47 48|..ABCDEFGH|

it contains a 0-byte string which is not empty! "BCDEFGH\0" (0).
It seems like it doesn't update the content of the string buffer / pointer to
it, but updates the length to be 0 instead of 1.

A correct/expected behaviour should be a 1-byte string: "A" (1).
A 0-byte string should be a result when the length field in the data structure
is set to `00 00`, and the contents of the string should be empty in that case,
not contain the previously stored value: "" (0).

My version of Okteta is 0.12.5, which from some reason wasn't on the list. (KDE
version 4.14.3)

-- 
You are receiving this mail because:
You are watching all bug changes.