Bug 203149 - news/slrn - dies in LC_ALL=C, LANG=C environment on some messages
Summary: news/slrn - dies in LC_ALL=C, LANG=C environment on some messages
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-16 07:42 UTC by parv
Modified: 2022-03-10 07:09 UTC (History)
3 users (show)

See Also:

Attachments
slrn --version output (524 bytes, text/plain)
2015-09-16 07:42 UTC, parv 		no flags Details
Backtrace of slrn.core on 10-STABLE (r286917) (2.17 KB, text/plain)
2015-09-16 07:43 UTC, parv 		no flags Details
Backtrace of slrn.core (slrn 1.0.3 on FreeBSD 11-STABLE r331758) (4.40 KB, text/plain)
2018-04-06 09:39 UTC, parv 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description parv 2015-09-16 07:42:27 UTC 
Created attachment 161105 [details]
slrn --version output

I had sent the following to slrn-user@ list; no resolution yet.

I came upon a post in rec.arts.anime.misc with Message-ID of ...

  8B8AD26D-FF8A-4CCE-A10A-239657B79B2E%anthony.baranyi@bell.net

... with headers ...

  Content-Type: text/plain; charset=windows-1250
  Content-Transfer-Encoding: binary

... which caused slrn to die with segfault. It was when "LC_ALL" was
set to "C" (no other LC_* variable was set).

slrn also dies while trying to display a reply to that post...

  slrnmtekva.3i0.alan@video.sabir.com


... which has ...

  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit

Previously, slrn would just show the odd charcaters without fuss,
which would be the desired behaviour. Problem remained even after
rebuilding slrn & slang.

The two messages can be accessed from ...

  http://bitter-almonds.com/tmp/slrn-segfault-LC_ALL=C

slrn displayed the messages without problem with ...

  LC_TIME=en_US.UTF-8
  LC_NUMERIC=en_US.UTF-8
  LC_MONETARY=en_US.UTF-8
  LC_MESSAGES=en_US.UTF-8
  LC_CTYPE=en_US.UTF-8
  LC_COLLATE=en_US.UTF-8
Comment 1 parv 2015-09-16 07:43:16 UTC 
Created attachment 161106 [details]
Backtrace of slrn.core on 10-STABLE (r286917)
Comment 2 Johan van Selst freebsd_committer freebsd_triage 2015-09-20 13:16:30 UTC 
Awaiting response from upstream
Comment 3 Jason Howe 2017-05-02 18:00:11 UTC 
Just hit this same issue with slrn 1.0.3 on 11.0-RELEASE-p10.

Setting the LC_* variables in my .bash_profile seem to have fixed the issue for me as well.
Comment 4 Walter Schwarzenfeld freebsd_triage 2018-02-02 11:10:40 UTC 
Is this still relevant?
Comment 5 parv 2018-04-06 09:37:09 UTC 
I am sorry to report that problem still exists if LC_ALL=C & LANG is unset or is C (but not if LC_ALL=en_US.UTF-8 with LANG also set to the same value; no other LC* variable is set) ...


slrn --version
slrn 1.0.3
S-Lang Library Version: 2.3.1
Operating System: FreeBSD

COMPILE TIME OPTIONS:
 Backends: +nntp +slrnpull +spool
 External programs / libs: -canlock -inews +ssl +uudeview +iconv
 Features: +decoding +emphasized_text +end_of_thread +fake_refs +gen_msgid
    -grouplens -msgid_cache +piping +rnlock +spoilers -strict_from
 Using 64 bit integers for article numbers.

DEFAULTS:
 Default server object:     nntp
 Default posting mechanism: nntp


This time I am not able to pinpoint a particular message; stack trace is attached.
Comment 6 parv 2018-04-06 09:39:34 UTC 
Created attachment 192276 [details]
Backtrace of slrn.core (slrn 1.0.3 on FreeBSD 11-STABLE r331758)
Comment 7 Rene Ladan freebsd_committer freebsd_triage 2019-11-04 21:27:19 UTC 
Maintainer reset.
Comment 8 parv 2022-03-10 07:09:05 UTC 
Does not look like any progress would happen; I will close it.