[OmniOS-discuss] sed on bloody crashes when compiling cdrtools

[Dan Vatca]

Yes. And it also reproduces with a simple transliteration. But it does go
awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also
work just fine.

root at bloody:/var/cores# ls
root at bloody:/var/cores# env
HZ=
SHELL=/usr/bin/bash
TERM=xterm
LC_ALL=en_US.UTF-8
PAGER=/usr/bin/less -ins
MAIL=/var/mail/root
PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin
PWD=/var/cores
LANG=en_US.UTF-8
TZ=Europe/Bucharest
SHLVL=1
HOME=/root
LOGNAME=root
OLDPWD=/root
_=/usr/gnu/bin/env
root at bloody:/var/cores# uname -a
SunOS bloody 5.11 omnios-fa65b1e i86pc i386 i86pc
root at bloody:/var/cores# *echo "x" | /usr/bin/sed 'y%,%,%'*
Segmentation Fault (core dumped)
root at bloody:/var/cores# ls
core  core.sed.971
root at bloody:/var/cores# pstack core.sed.971
core 'core.sed.971' of 971:     /usr/bin/sed y%,%,%
 feeb67b9 _UTF8_mbsnrtowcs (0, 80474fc, ffffffff, 0, 0, 3) + 2d
 feea8d8b mbsrtowcs_l (0, 80474fc, 0, 0, fee01a00, 8067d66) + 35
 feea8dcf mbsrtowcs (0, 80474fc, 0, 0, 0, 0) + 42
 08053f2b compile_tr (8067d61, 806a274, 0, fee10268, 58, fee10048) + 132
 08054939 compile_stream (806a260, 8047e18, 8047dd8, 80531a8, 1, 8047ee1) +
7b8
 08054af0 compile  (0, 3, fef6ec80, 0, 100, feffb0a4) + 10
 080531b3 main     (8047dcc, fef72668, 8047e0c, 805251b, 2, 8047e18) + 1a8
 0805251b _start   (2, 8047ed4, 8047ee1, 0, 8047ee8, 8047eec) + 83
root at bloody:/var/cores# echo "a" | /usr/bin/sed 'y%a%b%'
Segmentation Fault (core dumped)
root at bloody:/var/cores# echo "a" | /usr/gnu/bin/sed 'y%a%b%'
b
root at bloody:/var/cores# echo "x" | /usr/bin/sed 's%,%,%'
x



On Fri, Sep 12, 2014 at 5:28 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Sep 12, 2014, at 9:19 AM, Dan Vatca <dan at syneto.net> wrote:
>
> > I'm compiling omnios bloody and I get this crash during cdrtools
> compilation:
> >
> > make: Warning: Ignoring DistributedMake -j option
> > <------>==> MAKING SYMLINKS in ./RULES/
> > sh: line 1: 14171: Memory fault(coredump)
> > mksh: Fatal error: The command `uname -s | sed
> 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()"%abcdefghijklmnopqrstuvwxyz,------%''
> returned status `0'
> >
> > This creates a core with this stack trace:
> > root at bloody:/var/cores# mdb core.sed.6628
> > Loading modules: [ libc.so.1 ld.so.1 ]
> >> ::walk thread | ::findstack -v
> > stack pointer for thread 1: 80462a8
> > [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ]
> > 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7)
> > 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0)
> > 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38)
> > 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1,
> 8047d60)
> > 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4)
> > 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c)
> > 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd)
> >
> > Did anyone else run into this?
>
> No, but I'm off bloody for now... (trying to bringup 012 and 013), and
> trying to beat back serious IPS problems I accidentally introduced.
>
> Can you reproduce this crash with just the command listed above all by
> itself?
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140912/b4f5cfe1/attachment.html>