[Bug 932621] Re: String corruption

[Sebastian Unger]

Hi Adam,

unfortunately I no longer work at that company and so can't retest
this issue. I have included Keith in the address list who is still
working there and may be able to retest this.

Cheers,
Seb

On Sun, Feb 10, 2013 at 12:43 PM, Adam Conrad <adconrad at 0c3.net> wrote:
> Is this issue still reproducible?  Can I get a testcase for it, or some
> sort of hint as to how to reproduce it?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/932621
>
> Title:
>   String corruption
>
> Status in “eglibc” package in Ubuntu:
>   New
>
> Bug description:
>   Hi there,
>
>   I'm installing a 64 bit ubuntu server system with oneiric. However,
>   due to https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/905660
>   I am trying to pull in ifupdown from precise. This pulls in the
>   following additional packages from precise due to dependencies:
>
>   libc-bin
>   libc-dev-bin
>   libc6
>   libc6-dev
>   libc6-dev-i386
>   libc6-i386
>   libnih-dbus1
>   libnih1
>
>   The oneiric version of the libc packages is 2.13-20ubuntu5.
>   The precise version of the libc packages is 2.15-0ubuntu2.
>
>   After this, a i386 application that I have installed on the machine
>   breaks. The application is multi V4.2.4 from Green Hills. It is their
>   proprietary compiler suite and IDE. When I use this compiler suite to
>   compiler our embedded application, it fails to find a particular
>   library. Upon further investigation I found that the front-end
>   compiler driver (gbuild) passed the wrong library search path down to
>   the compiler. The output of ldd gbuild is:
>
>   la:~/trunk $ ldd /usr/ghs/multi424/gbuild
>           linux-gate.so.1 =>  (0xf774d000)
>           libm.so.6 => /lib32/libm.so.6 (0xf7710000)
>           libnsl.so.1 => /lib32/libnsl.so.1 (0xf76f7000)
>           libdl.so.2 => /lib32/libdl.so.2 (0xf76f2000)
>           libc.so.6 => /lib32/libc.so.6 (0xf7578000)
>           /lib/ld-linux.so.2 (0xf774e000)
>
>   With the oneiric version of the above packages, gbuild passing the
>   (correct) option -L../output/ppc to the compiler. With the precise
>   version of these libraries gbuild passes -L../outuut/ppc to the
>   compiler. gbuild gets the path from a config file, which actually
>   contains the option -L../../output/ppc, but is located one directory
>   below the current working directory of the compiler invocation and is
>   defined to be local to that file.
>
>   So I suspect that gbuild recognizes the -L option and the fact that
>   it's argument is a relative path (another -L in the same file with an
>   absolute path is passed through correctly) and tries to strip off the
>   initial ../ but something goes wrong. I also suspect that the bug only
>   shows up in the 32bit version of libc on 64 bit systems, since all my
>   64 bit apps seem to behave normally.
>
>   I can modify the option in the config file to check what, if any,
>   corruption occurs to different strings. Here are some results:
>
>   -L../../output/ppc   =>  -L../outuut/ppc  (corrupted, that's the one that I found this with)
>   -L../../../output/ppc   =>  -L../../output/ppc   (correct, no corruption)
>   -L./../../output/ppc   =>  -Lshared-libs/.../output/ppppc  (corrupted, shared-libs is the directory that the config file resides in)
>   -L./../output/ppc   => -Loutput/ppc    (correct, no corruption)
>   -L.././../output/ppc  =>  -L../output/ppc    (correct, no corruption)
>   -L../.././output/ppc  =>  -L../output/ppc  (correct, no corruption)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/932621/+subscriptions

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/932621

Title:
  String corruption

Status in “eglibc” package in Ubuntu:
  New

Bug description:
  Hi there,

  I'm installing a 64 bit ubuntu server system with oneiric. However,
  due to https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/905660
  I am trying to pull in ifupdown from precise. This pulls in the
  following additional packages from precise due to dependencies:

  libc-bin
  libc-dev-bin
  libc6
  libc6-dev
  libc6-dev-i386
  libc6-i386
  libnih-dbus1
  libnih1

  The oneiric version of the libc packages is 2.13-20ubuntu5.
  The precise version of the libc packages is 2.15-0ubuntu2.

  After this, a i386 application that I have installed on the machine
  breaks. The application is multi V4.2.4 from Green Hills. It is their
  proprietary compiler suite and IDE. When I use this compiler suite to
  compiler our embedded application, it fails to find a particular
  library. Upon further investigation I found that the front-end
  compiler driver (gbuild) passed the wrong library search path down to
  the compiler. The output of ldd gbuild is:

  la:~/trunk $ ldd /usr/ghs/multi424/gbuild 
          linux-gate.so.1 =>  (0xf774d000)
          libm.so.6 => /lib32/libm.so.6 (0xf7710000)
          libnsl.so.1 => /lib32/libnsl.so.1 (0xf76f7000)
          libdl.so.2 => /lib32/libdl.so.2 (0xf76f2000)
          libc.so.6 => /lib32/libc.so.6 (0xf7578000)
          /lib/ld-linux.so.2 (0xf774e000)

  With the oneiric version of the above packages, gbuild passing the
  (correct) option -L../output/ppc to the compiler. With the precise
  version of these libraries gbuild passes -L../outuut/ppc to the
  compiler. gbuild gets the path from a config file, which actually
  contains the option -L../../output/ppc, but is located one directory
  below the current working directory of the compiler invocation and is
  defined to be local to that file.

  So I suspect that gbuild recognizes the -L option and the fact that
  it's argument is a relative path (another -L in the same file with an
  absolute path is passed through correctly) and tries to strip off the
  initial ../ but something goes wrong. I also suspect that the bug only
  shows up in the 32bit version of libc on 64 bit systems, since all my
  64 bit apps seem to behave normally.

  I can modify the option in the config file to check what, if any,
  corruption occurs to different strings. Here are some results:

  -L../../output/ppc   =>  -L../outuut/ppc  (corrupted, that's the one that I found this with)
  -L../../../output/ppc   =>  -L../../output/ppc   (correct, no corruption)
  -L./../../output/ppc   =>  -Lshared-libs/.../output/ppppc  (corrupted, shared-libs is the directory that the config file resides in)
  -L./../output/ppc   => -Loutput/ppc    (correct, no corruption)
  -L.././../output/ppc  =>  -L../output/ppc    (correct, no corruption)
  -L../.././output/ppc  =>  -L../output/ppc  (correct, no corruption)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/932621/+subscriptions