Re: [gentoo-user] Maybe bug? (glibc related?)

[Elias Diem]

Hi lee

On 2015-12-30, lee wrote:

> Elias Diem <li...@webconect.ch> writes:
> 
> >> Whether this is a bug or not depends on what you're supposed to expect,
> >> which I don't know.  If someone would run the test suite on a
> >> non-hardened profile and got the same warning from gcc, but vim wouldn't
> >> be terminated when the segmentation fault occurs, then I'd be worried.
> >
> > Ok. Well, I don't know either what to expect. I haven't got 
> > enough knowledge to analyse this. I posted it here because I 
> > was told so ;-)
> 
> Maybe someone knows ...
> 
> How do you run the test thing?  I could try and see what happens.

I clone the git repo at https://github.com/vim/vim and work 
with that.

I've got a file at http://webconect.ch/cont/vim/myenv that I 
source prior to make. For example:

$ cd vim
$ . myenv
$ make

Then, to run Vim's testsuite:

$ make test

Note that `make test` only fails if I compile with -O1.

-- 
Greetings
Elias

Re: [gentoo-user] Maybe bug? (glibc related?)

[Elias Diem]

Hi lee

On 2015-12-29, lee wrote:

> When you perform a strcpy() and overflow the destination buffer, you are
> supposed to experience a segmentation fault.  It shouldn't matter
> whether you run a hardened profile or not for detecting these.

Ok. Thanks for the explanation.

> I imagine it was discovered that a segmentation fault did occur, and
> that it inevitably would occur --- since gcc tells you that one will
> occur when using __builtin___strcpy_chk() --- and the application was
> terminated.  Otherwise, the test would have been unsuccessful.

Ok.

> Whether this is a bug or not depends on what you're supposed to expect,
> which I don't know.  If someone would run the test suite on a
> non-hardened profile and got the same warning from gcc, but vim wouldn't
> be terminated when the segmentation fault occurs, then I'd be worried.

Ok. Well, I don't know either what to expect. I haven't got 
enough knowledge to analyse this. I posted it here because I 
was told so ;-)

-- 
Greetings
Elias

Re: [gentoo-user] Maybe bug? (glibc related?)

[Elias Diem]

Hi lee

On 2015-12-29, lee wrote:

> Elias Diem <li...@webconect.ch> writes:
> 
> > Hi
> >
> > I just got the following while running Vim's testsuite.
> >
> > 
> > *** buffer overflow detected ***: vim terminated; report to 
> > <http://bugs.gentoo.org/>
> > Makefile:151: recipe for target 'af.ck' failed
> > make[2]: *** [af.ck] Killed
> > 
> >
> > The compiler gave me the following warning.
> >
> > [...]
> > /usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk 
> > will always overflow destination buffer
> >return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
> >
> > [...]
> >
> > Should I file a bug?
> 
> The test was successful because the buffer overflow was detected?

I think I don't quite understand your question.

`make test` failed. Therefore I'd say the test was not 
successful.

I run a hardened profile. I guess that's why the overflow 
was detected and vim terminated.

-- 
Greetings
Elias

[gentoo-user] Maybe bug? (glibc related?)

[Elias Diem]

Hi

I just got the following while running Vim's testsuite.


*** buffer overflow detected ***: vim terminated; report to 

Makefile:151: recipe for target 'af.ck' failed
make[2]: *** [af.ck] Killed


The compiler gave me the following warning.


gcc -c -I. -Iproto -DHAVE_CONFIG_H  -O1 -o objects/if_cscope.o 
if_cscope.c
In file included from /usr/include/string.h:639:0,
 from os_unix.h:542,
 from vim.h:282,
 from eval.c:14:
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24061:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘call_user_func’ at eval.c:24067:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24082:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24084:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^


This seems to only happen with -O1. I don't get this 
behaviour with -O2.

Do you need more info?

Should I file a bug?

-- 
Greetings
Elias

Re: [gentoo-user] troubles with mutt+gnupg

[Elias Diem]

Hi Michael

On 2014-04-27,  Michael Mair-Keimberger wrote:

 snip/
 
 Any ideas whats wrong here?

Unfortunately no. But you may try the mutt mailing list. 
It's at mutt-us...@mutt.org

-- 
Greetings
Elias

Re: [gentoo-user] D and Gentoo

[Elias Diem]

Hi there

Just for the records.

I finally managed to build GCC with D support myself 
(without using the overlay).

What I did:

- Download and enpack a tar for GCC 4.8.2

- Clone the git repo from gdcproject.org

- Check out the appropriate branch in the git repo

- Run the setup-gcc.sh script

- Configure GCC (including --enable-languages=d)

- Make GCC

-- 
Greetings
Elias

Re: [gentoo-user] Re: D and Gentoo

[Elias Diem]

On 2014-01-12,  walt wrote:

 I know absolutely nothing about D, which makes me qualified to ask
 how you can tell if the 'd' useflag is working or not ;)

Hehe. Good question.

Well I enabled this USE flag for gcc but I don't have an 
executable that starts with

gcc...
gdc...

And furthermore if I run 'equery u gcc' there is no d USE 
flag. It's not even there to tell me that gcc was compiled 
without it!

-- 
Greetings
Elias

Re: [gentoo-user] Re: D and Gentoo

[Elias Diem]

Hi Pavel

On 2014-01-13,  Pavel Kazakov wrote:

 According to 'euse -i d', the 'd' flag only shows up for
 '=sys-devel/gcc-3.4.6-r2' and '=sys-devel/gcc-4.1.2'. I'm assuming you
 are using a newer version of gcc that doesn't have the d use flag.

Indeed. Thank you for the explanation.


-- 
Greetings
Elias

[gentoo-user] D and Gentoo

[Elias Diem]

Hi all

What's the best way to have a D compiler in Gentoo?

I know that there is a USE flag for gcc which adds D, but 
apparently it doesn't work.

-- 
Greetings
Elias

Re: [gentoo-user] uzbl

[Elias Diem]

Hi Walter

On 2013-12-08,  Walter Dnes wrote:

 Believe me, you will want uzbl-tabbed, not uzbl-browser.

Yes indeed. I use uzbl-tabbed now.

   There is a mailing list at snip/

Thanks for the info.

-- 
Greetings
Elias

[gentoo-user] uzbl

[Elias Diem]

Hello there

I've got a problem with uzbl, a web browser.

The install works fine. I can also start the program. 
However it seems that uzbl doesn't want to listen to any 
keystrokes I type. For example 'o' to open an URL does 
nothing.

Is anybody else here using uzbl and can help me with the 
problem?

*  www-client/uzbl
  Latest version available: 2011.04.12
  Latest version installed: 2011.04.12

I run amd64.

Thanks.

-- 
Greetings
Elias

Re: [gentoo-user] uzbl

[Elias Diem]

Hi Tim

On 2013-12-06,  Tim Millican wrote:

 I had the exact same problem when I switched, but its a pretty easy fix.
 UZBL is written to use Python 2, so you either have to set that as your 
 default
 in `eselect python`, or change the shebang at the top of 
 /usr/bin/uzbl-event-manager
 to explicitly use Python2. (Change ''#!/usr/bin/env python' to 
 '#!/usr/bin/env python2')

Thank you. That was the fix. I opted for the second 
approach.

-- 
Greetings
Elias

Re: [gentoo-user] uzbl

[Elias Diem]

On 2013-12-06,  Tim Millican wrote:

 I had the exact same problem when I switched, but its a pretty easy fix.
 UZBL is written to use Python 2, so you either have to set that as your 
 default
 in `eselect python`, or change the shebang at the top of 
 /usr/bin/uzbl-event-manager
 to explicitly use Python2. (Change ''#!/usr/bin/env python' to 
 '#!/usr/bin/env python2')

If I had searched hard enough I'd found this:

https://bugs.gentoo.org/show_bug.cgi?id=456310

-- 
Greetings
Elias

Re: [gentoo-user] uzbl

[Elias Diem]

Or this:

https://bugs.gentoo.org/show_bug.cgi?id=490348

-- 
Greetings
Elias

[gentoo-user] Which Radeon Firmware?

[Elias Diem]

Hi all

I've got a Radeon graphics card and I don't know which 
firmware to use. My model doesn't seem to be listed on 
https://wiki.gentoo.org/wiki/Radeon#Firmware

Here is  the output from lspci:

output
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Trinity 
[Radeon HD 7560D] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device 1850
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at d000 (32-bit, prefetchable) [size=256M]
I/O ports at f000 [size=256]
Memory at ff70 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at unassigned [disabled]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ?
Kernel driver in use: radeon
/output

What firmware would you use?

Thanks

-- 
Greetings
Elias

Re: [gentoo-user] Which Radeon Firmware?

[Elias Diem]

Hi Bruce

On 2013-11-11,  Bruce Hill wrote:

 If you have CONFIG_DRM_RADEON=m, and
 CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware/, then the kernel will pick the
 right firmware automatically, without having to name the microcode in
 CONFIG_EXTRA_FIRMWARE at all.

Yes, thank you. It worked.

 Build your kernel that way and see which firmware shows up issuing:
 dmesg | grep -i firmware

Unfortunately I can't figure it out.

'dmesg | grep -i firmware' doesn't return anything.

'dmesg | grep -i radeon' returns:

snip
[0.030492] smpboot: CPU0: AMD A8-5500B APU with Radeon(tm) HD Graphics 
(fam: 15, model: 10, stepping: 01)
[4.600599] [drm] radeon kernel modesetting enabled.
[4.601157] radeon :00:01.0: VRAM: 768M 0x - 
0x2FFF (768M used)
[4.601159] radeon :00:01.0: GTT: 512M 0x3000 - 
0x4FFF
[4.601693] [drm] radeon: 768M of VRAM memory ready
[4.601694] [drm] radeon: 512M of GTT memory ready.
[4.881482] radeon :00:01.0: WB enabled
[4.881485] radeon :00:01.0: fence driver on ring 0 use gpu addr 
0x3c00 and cpu addr 0x880223f0dc00
[4.882218] radeon :00:01.0: fence driver on ring 5 use gpu addr 
0x00075a18 and cpu addr 0xc900114b5a18
[4.882220] radeon :00:01.0: fence driver on ring 1 use gpu addr 
0x3c04 and cpu addr 0x880223f0dc04
[4.88] radeon :00:01.0: fence driver on ring 2 use gpu addr 
0x3c08 and cpu addr 0x880223f0dc08
[4.882223] radeon :00:01.0: fence driver on ring 3 use gpu addr 
0x3c0c and cpu addr 0x880223f0dc0c
[4.882225] radeon :00:01.0: fence driver on ring 4 use gpu addr 
0x3c10 and cpu addr 0x880223f0dc10
[4.882245] radeon :00:01.0: irq 45 for MSI/MSI-X
[4.882255] radeon :00:01.0: radeon: using MSI.
[4.882534] [drm] radeon: irq initialized.
[5.023269] [drm] Radeon Display Connectors
[5.044982] [drm] radeon: power management initialized
[5.165005] fbcon: radeondrmfb (fb0) is primary device
[5.231602] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[5.231604] radeon :00:01.0: registered panic notifier
[5.231608] [drm] Initialized radeon 2.33.0 20080528 for :00:01.0 on 
minor 0
/snip

-- 
Greetings
Elias

Re: [gentoo-user] Bug in spidermonkey? SOLVED!!

[Elias Diem]

Hello there

Just for the record: I was able to solve the problem!!

I created a separate environment file in /etc/portage/env.

The content of this file is:

-8---

CFLAGS=-pipe 
CXXFLAGS=${CFLAGS} 

MAKEOPTS=-j1 

-8---

The CFLAGS normally is -02 -pipe -march=k8  and the job 
count for make is 4.

I guess I can further tune the process now.

-- 
Greetings
Elias

Re: [gentoo-user] Bug in spidermonkey?

[Elias Diem]

Hi there

Well I did reinstall my whole system but without luck. 
Emerging gnome-light showed the very same error when 
compiling spidermonkey.

Then I thought I will install awesome, because it does not 
need spidermonkey. But the same problem here when compiling 
awesome. `Illegal statement' in the build.log.

Next I thought about installing xmonad. And this time it 
worked. So I will use xmonad for the future.

Thanks for your help Nilesh and Walt!

-- 
Greetings
Elias

Re: [gentoo-user] Bug in spidermonkey?

[Elias Diem]

On 2013-02-12,  Elias Diem wrote:

 `Illegal statement' in the build.log.

The above should read `Illegal instruction'.

-- 
Greetings
Elias

Re: [gentoo-user] Re: Bug in spidermonkey?

[Elias Diem]

Hi Walt

On 2013-02-08,  walt wrote:

 I just built 1.8.5-r1 on my ~amd64 machine without errors, and I have 1.8.5-r4
 already installed.  Can you unmask and compile r4 just as a test?

I tried the r4 version but it failed the same way.

 BTW, in your build log I see waiting for unfinished jobs, so it would be 
 worth
 trying -j1 instead of -j4.  Your stable build tools are no doubt very 
 different
 from the versions I'm running on ~amd64.  Just another random thing to try in
 a puzzling situation...

I also (additionally) set the MAKEOPTS to -j1 and it failed 
as well.

I guess I'm going to reinstall the whole system.

-- 
Greetings
Elias

Re: [gentoo-user] Re: Bug in spidermonkey?

[Elias Diem]

Hi Walt

On 2013-02-07,  walt wrote:

 Any time perl is involved in a bug I suggest running 'perl-cleaner'.  May not
 help, but it couldn't hurt :)

Unfortunately it didn't help...

-- 
Greetings
Elias

Re: [gentoo-user] Bug in spidermonkey?

[Elias Diem]

On 2013-02-07,  Nilesh Govindrajan wrote:

 Seems like one. Try compiling an older version?

Actually I can compile version 1.7.0

But: When I want to update world, it needs (I think) version 
1.8.5-r1

-- 
Greetings
Elias

[gentoo-user] Bug in spidermonkey?

[Elias Diem]

Hello all

I'm encountering a bug when emerging spidermonkey.

The output from build.log is attached.

If you need more info, please tell me so.

Thanks.

-- 
Greetings
Elias


 * Package:dev-lang/spidermonkey-1.8.5-r1
 * Repository: gentoo
 * Maintainer: mozi...@gentoo.org
 * USE:abi_x86_64 amd64 elibc_glibc kernel_linux 
multilib userland_GNU
 * FEATURES:   sandbox
 Unpacking source...
 Unpacking js185-1.0.0.tar.gz to 
 /var/tmp/portage/dev-lang/spidermonkey-1.8.5-r1/work
 Source unpacked in /var/tmp/portage/dev-lang/spidermonkey-1.8.5-r1/work
 Preparing source in 
 /var/tmp/portage/dev-lang/spidermonkey-1.8.5-r1/work/js-1.8.5 ...
 * Applying spidermonkey-1.8.5-fix-install-symlinks.patch ...
 [ ok ]
 * Applying spidermonkey-1.8.5-fix-ppc64.patch ...
 [ ok ]
 * Applying spidermonkey-1.8.5-arm_respect_cflags-3.patch ...
 [ ok ]
 * Applying spidermonkey-1.8.7-freebsd-pthreads.patch ...
 [ ok ]
 * Applying spidermonkey-1.8.5-perf_event-check.patch ...
 [ ok ]
 * Running autoconf ...
 [ ok ]
 Source prepared.
 Configuring source in 
 /var/tmp/portage/dev-lang/spidermonkey-1.8.5-r1/work/js-1.8.5 ...
 * econf: updating js-1.8.5/js/src/ctypes/libffi/config.sub with 
/usr/share/gnuconfig/config.sub
 * econf: updating js-1.8.5/js/src/ctypes/libffi/config.guess with 
/usr/share/gnuconfig/config.guess
 * econf: updating js-1.8.5/js/src/build/autoconf/config.sub with 
/usr/share/gnuconfig/config.sub
 * econf: updating js-1.8.5/js/src/build/autoconf/config.guess with 
/usr/share/gnuconfig/config.guess
./configure --prefix=/usr --build=x86_64-pc-linux-gnu 
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info 
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib 
--libdir=/usr/lib64 --enable-jemalloc --enable-readline --enable-threadsafe 
--with-system-nspr --disable-debug --disable-static --disable-tests
creating cache ./config.cache
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking build system type... x86_64-pc-linux-gnu
checking for mawk... no
checking for gawk... gawk
checking for perl5... no
checking for perl... /usr/bin/perl
checking for gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe  
-Wl,-O1 -Wl,--as-needed) works... yes
checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe  
-Wl,-O1 -Wl,--as-needed) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for c++... x86_64-pc-linux-gnu-g++
checking whether the C++ compiler (x86_64-pc-linux-gnu-g++ -march=k8 -O2 -pipe  
 -Wl,-O1 -Wl,--as-needed) works... yes
checking whether the C++ compiler (x86_64-pc-linux-gnu-g++ -march=k8 -O2 -pipe  
 -Wl,-O1 -Wl,--as-needed) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether x86_64-pc-linux-gnu-g++ accepts -g... yes
checking for ranlib... ranlib
checking for as... /usr/bin/as
checking for ar... ar
checking for ld... x86_64-pc-linux-gnu-ld
checking for strip... strip
checking for windres... no
checking whether x86_64-pc-linux-gnu-gcc and cc understand -c and -o 
together... yes
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking how to run the C++ preprocessor... x86_64-pc-linux-gnu-g++ -E
checking for sb-conf... no
checking for ve... no
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for minimum required perl version = 5.006... 5.012004
checking for full perl installation... yes
checking for python2.7... /usr/bin/python2.7
checking for doxygen... :
checking for autoconf... /usr/bin/autoconf
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for makedepend... /usr/bin/makedepend
checking for xargs... /usr/bin/xargs
checking for gmake... /usr/bin/gmake
checking for X... libraries , headers 
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking whether the compiler supports -Wno-invalid-offsetof... yes
checking whether the compiler supports -Wno-variadic-macros... yes
checking whether the compiler supports -Werror=return-type... yes
checking whether ld has archive extraction flags... yes
checking that static assertion macros used in autoconf tests work... yes
checking for 64-bit OS... yes
checking for Python version = 2.5 but not 

Re: [gentoo-user] Bug in spidermonkey?

[Elias Diem]

Hi Nilesh

On 2013-02-07,  Nilesh Govindrajan wrote:

 Seems like one. Try compiling an older version?

I'm about to try. I will report back.

-- 
Greetings
Elias