Bug 7798 - ThinLinc on Linux client will crash if tlclient.log is empty or has a malformed first line
Summary: ThinLinc on Linux client will crash if tlclient.log is empty or has a malform...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Linn
URL:
Keywords: relnotes, wilsj_tester
Depends on:
Blocks:
 
Reported: 2021-11-18 14:35 CET by Martin Östlund
Modified: 2021-12-08 11:10 CET (History)
3 users (show)

See Also:
Acceptance Criteria:
* The client should be able to start with: - An empty log file. - A log file containing 20 characters or less. - A 'normal' log file.


Attachments

Description Martin Östlund cendio 2021-11-18 14:35:08 CET
Summary
=========
ThinLinc Client 4.13.0-2172 on Linux platforms will crash if ~/.thinlinc/tlclient.log exists but is empty, or first line is less then 21 characters long.

Results
========
maros@maros:~$ tlclient
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 21) > this->size() (which is 0)
Aborted


Howto reproduce
================
1. rm ~/.thinlinc/tlclient.log && touch ~/.thinlinc/tlclient.log
2. Start tlclient
3. Watch it crash


Expected results
=================
ThinLinc client should not crash.
Comment 3 Linn cendio 2021-12-02 16:51:14 CET
Tested with a locally built client on Fedora 33 and macOS 12, and the client is able to start even if the log file has a bad first line.

The client can start with: 
  ✓ An empty log file.
  ✓ A log file containing 20 characters or less.
  ✓ A 'normal' log file.

Also shallowly tested that the handling of multiple log files still work, even with log files with bad first lines.

The code changes only concerns Linux and macOS, so the windows client does not need to be tested.
Comment 4 William Sjöblom cendio 2021-12-08 11:10:32 CET
I successfully reproduce the crash with ThinLinc client 4.13.0 on Fedora
34.

With client build #2287 I then verified all acceptance criteria on
Fedora 34 and macOS without any issues.

On top of this I also did some investigation into different variations of
the first log file line from which we parse the pid:
• Without a log file pid of the first line (and just a trailing space)
  gets interpreted as a tlclient pid of 0 which is handled gracefully.
• With alpha garbage at the end of the first line (instead of a pid) we
  the log file pid is interpreted as 0 which is handled gracefully.
• With a log file pid above `LONG_MAX' or below `LONG_MIN' we get a
  tlclient pid clamped to said limit which is handled gracefully.
• Negative log file pids are handled gracefully.

Marking as closed.

Note You need to log in before you can comment on or make changes to this bug.