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: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Johan van Selst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-16 07:42 UTC by parv
Modified: 2018-04-06 09:39 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (johans)


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

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 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 w.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)