bugGNU Octave - Bugs: bug #30478, prelinking causes octave to crash

 
 

bug #30478: prelinking causes octave to crash

Submitter:  Alex Lancaster <alexl>
Submitted:  Sun 18 Jul 2010 09:01:06 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 25 Feb 2012 08:18:23 PM UTC, comment #29: 

Echoing Jordi, is this still a problem with the 3.6.1 release which is now widely available here (http://www.gnu.org/software/octave/download.html)?

Rik <rik5>
Group administrator
Sun 29 Jan 2012 12:12:55 AM UTC, comment #28: 

Is this problem still present in the 3.6.0 release?

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Tue 02 Nov 2010 12:16:58 PM UTC, comment #27: 

Sorry, Gotoblas site says :
# Do not redistribute the library.
# Point others to this web page instead :
http://www.tacc.utexas.edu/?id=98

An e-mail has been sent to the Gotoblas maintainer,
to see if the rule can be relaxed in our case.


John Hunt <huntj>
Mon 01 Nov 2010 11:19:20 AM UTC, comment #26: 

Could you provide your prelinked (as-is) binary:
/usr/local/share/GotoBLAS2/libgoto2_nehalemp-r1.13.so

I will try to match the instruction to its source.

Jan Kratochvil <lace>
Tue 26 Oct 2010 02:53:20 PM UTC, comment #25: 

The initial bug report is about prelinking.
By chance I found out another crash that disappears when
prelinking is off, so I found relevant to post findings here.
Please tell me if I'm wrong.

My bug requires a sequence of launching and exiting octave in two
terminals, as described in comment #8.
Maybe it is because there are launch/exit of one instance of
octave while another is running.
Tests run fine because there is only one terminal opened at that
time.

Here is the output of
gdb -nx /usr/local/bin/octave core
(gdb) where
#0  0x00007f3e051df4e8 in ?? () from /usr/local/share/GotoBLAS2/libgoto2_nehalemp-r1.13.so
#1  0x0000000000000000 in ?? ()

The problem is that the crash happens only when there are no
debugging symbols in the executable (see comment #19),
that's the reason for having in the backtrace those
"in ?? ()", isn't it ?


John Hunt <huntj>
Tue 26 Oct 2010 08:59:47 AM UTC, comment #24: 

Now I'm getting a bit confused.  Is this bug report about prelinking or what?

You say that Octave runs and passes make check, but crashes on startup if you install it?  I have no clue why that would happen.

What happens if you run gdb on your core file and type

  where

at the (gdb) prompt?  Does that give any useful information about where in Octave the crash is happening?  If you can't say where in Octave the crash is happening, then I think I'll have to give up trying to debug this problem.

I would not expect that you should have to copy exactly the compiler flags used to compile your BLAS library, provided that pointers and ints have the correct sizes.  Unless you are compiling Octave with --enable-64, pointers on a 64-bit system are assumed to be 8 bytes but integers are 4 bytes.  I think that is what -m64 does, so it should be OK.  And I think that is also the default for a 64-bit system, so should not really be necessary.  But anyway, if Octave does run make check successfully, I don't see how this could be the problem.

John W. Eaton <jwe>
Group administrator
Tue 26 Oct 2010 08:44:13 AM UTC, comment #23: 

GotoBlas did not use exactly the same flags as octave,
but it is not the reason for the crash.


Here are two sample lines from Gotoblas build :

gfortran -O2 -m128bit-long-double -Wall  -m64 -fPIC  -c dsterf.f -o dsterf.o

gcc -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC  -DSMP_SERVER -DMAX_CPU_NUMBER=12 -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -I.. -w -o linktest linktest.c ../libgoto2_nehalemp-r1.13.so -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../..  -lgfortran -lm -lgfortran -lm -lc   && echo OK.
OK.

After changing the flags for octave accordingly
make distclean
CXXFLAGS="-O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -fPIC" FFLAGS="-O2 -m128bit-long-double -Wall  -m64 -fPIC" ./configure --with-blas=/usr/local/share/GotoBLAS2/libgoto2_nehalemp-r1.13.so --without-arpack --without-qrupdate
make
make check => OK
make install

same crash


John Hunt <huntj>
Tue 26 Oct 2010 08:18:13 AM UTC, comment #22: 

The backtrace you provide doesn't help me much.  I can't tell where in Octave the call to the BLAS was made.  I can't even tell which function in the BLAS it is that the crash occurs, though it does seem to be happening there, as the first thing that gbd reports is about the 6 threads (presumably all created by your Goto BLAS library since Octave does not create any threads itself).

John W. Eaton <jwe>
Group administrator
Tue 26 Oct 2010 07:53:57 AM UTC, comment #21: 

following comment #20, after commenting out these lines,
the crash still occurs (backtrace appended)


(file #21825)

John Hunt <huntj>
Mon 25 Oct 2010 09:03:59 PM UTC, comment #20: 

Since the crash seems to be related to BLAS, here is a guess.  In the file src/octave.cc in the function octave_main, we have


 // The idea here is to force xerbla to be referenced so that we will
  // link to our own version instead of the one provided by the BLAS
  // library.  But octave_NaN should never be -1, so we should never
  // actually call xerbla.

  if (octave_NaN == -1)
    F77_FUNC (xerbla, XERBLA) ("octave", 13, 6L);


Does removing or commenting out these lines avoid the crash?

Also I just noticed that this call is probably not written correctly.  I think it should be


    F77_FUNC (xerbla, XERBLA) ("octave", 13, F77_CHAR_ARG_LEN (6));


instead, and I've made that change.  Though since the call should never be executed, I can't see the harm this mistake could cause, and with gfortran, I think the normal thing is to append the character string length as an extra argument, so it should probably work on GNU/Linux systems with gfortran anyway.

John W. Eaton <jwe>
Group administrator
Mon 25 Oct 2010 08:47:28 PM UTC, comment #19: 

some new facts, hoping it can help someone :
Even after recompilation of libgoto2,
and now using octave-3.3.53,
rpm -q preload
preload-1.1-18.2.x86_64

same crash when preload is enabled,
attached backtrace_localbinoctave generated with the magical
gdb -nx ... command given by Jan Kratochvil in comment #13

no crash with preload disabled.

with preload enabled, but running a stripped octave, as
cp /usr/local/bin/octave .
strip --strip-debug ./octave
./octave
yields the crash
backtrace_strippedoctave attached

So it may be that debugging symbols are stripped when preload is
enabled. But why would the presence of debugging symbols prevent
a crash ?


(file #21818, file #21819)

John Hunt <huntj>
Mon 18 Oct 2010 09:58:09 PM UTC, comment #18: 

Following comment #13 the output of
gdb -nx /usr/local/bin/octave core -ex 'thread apply all bt full' -ex 'info thread' -ex 'info shared' -ex q  > backtrace
on the core mentionned in comment #10
has been attached

libgoto2.so was the first lib appearing after the crash.

Compiling with unoptimized blas and lapack libs provided with
OpenSUSE 11.3 yields no crash.

Compiling with ATLAS 3.9.25 yields no crash also.

And the fork problem mentioned in comment #17 disappeared also. Nice.

A new octave compilation with libgoto2 brought the crash back.

So surely there was a mistake in my compilation of libgoto2 (1.13).

As for comment #14, the download works here, so I'll try to find
another storage place, if you still want the files ?


(file #21710)

John Hunt <huntj>
Mon 18 Oct 2010 06:15:24 PM UTC, comment #17: 

@jwe, comment #15

I appreciate all the work you are doing for the great software
octave is.
There is perhaps a misunderstanding. I do not expect anybody to work for me.
My skills are limited and, as already mentionned, running octave inside gdb lead to no crash, hence no backtrace. I'll try to follow what Jan Kratochvil suggested.

Working without octave preloading is not a problem to me.
Trying to solve another another strange thing, were octave
forked processes do not run in parallel (hence rending
parcellfun useless), I stumbled on this bug report because
after the crash and a precise procedure, the processes do run
in parallel. Very strange. I'm still on it.

Then I just thought the informations gathered after hours of investigations might help other people.


John Hunt <huntj>
Mon 18 Oct 2010 04:29:09 PM UTC, comment #16: 

I have installed http://download.opensuse.org/distribution/11.3/iso/ into KVM so I have now the SuSE system to reproduce this bug (to fix it in Fedora).

Jan Kratochvil <lace>
Mon 18 Oct 2010 04:25:46 PM UTC, comment #15: 

I guess it would also help if I had a SUSE System?  But I don't, and prelinking (which I also had not heard of until this bug report) seems like a special use case.  So if you want to see this problem fixed, I think the people who have the problem are going to have to do some debugging.  You have the core file and the binaary and all the libraries used to generate it, and the system where it was generated, so it seems like it would be simplest for you to run gdb on the core file and corresponding program and libraries rather than expecting us to do a lot of work to try to duplicate your system just to run a few commands in gdb.

John W. Eaton <jwe>
Group administrator
Mon 18 Oct 2010 04:19:37 PM UTC, comment #14: 

The comment #11 core file prints me:
Sorry, the page (or document) you have requested is not available.

Jan Kratochvil <lace>
Mon 18 Oct 2010 04:18:19 PM UTC, comment #13: 

It would help together with attached these files:
/usr/local/bin/octave
/usr/local/share/GotoBLAS2/libgoto2.so
/usr/local/lib/octave-3.3.52/liboctinterp-3.3.52.so
/usr/local/lib/octave-3.3.52/liboctave-3.3.52.so
/usr/local/lib/octave-3.3.52/libcruft-3.3.52.so
/usr/local/lib/libfftw3.so.3
/usr/local/lib/libfftw3f.so.3

Ensuring they still contain debug info (readelf -wi prints some gigantic dumps on them), during `make install' sometimes the debug info from -g gets stripped.

and rpm -qf of these files:
/usr/lib64/libfltk_gl.so.1.1
/usr/lib64/libfltk.so.1.1
/lib64/libpthread.so.0
/usr/lib64/libXext.so.6
/usr/lib64/libfreetype.so.6
/lib64/libz.so.1
/usr/lib64/libfontconfig.so.1
/usr/lib64/libGL.so.1
/usr/lib64/libGLU.so.1
/usr/lib64/libX11.so.6
/lib64/libreadline.so.6
/lib64/libncurses.so.5
/lib64/libpcre.so.0
/lib64/libdl.so.2
/usr/lib64/libgfortran.so.3
/lib64/libm.so.6
/lib64/libc.so.6
/usr/lib64/libstdc++.so.6
/lib64/libgcc_s.so.1
/lib64/ld-linux-x86-64.so.2
/lib64/libexpat.so.1
/usr/lib64/libXxf86vm.so.1
/usr/lib64/libXdamage.so.1
/usr/lib64/libXfixes.so.3
/usr/lib64/libdrm.so.2
/usr/lib64/libxcb.so.1
/lib64/librt.so.1
/usr/lib64/libXau.so.6

The problem with gdb is that usually this kind of problems is not reproducible when being debugged.  You have a better reproducibility chance in GDB to also use `set disable-randomization off'.

gdb -nx /usr/local/bin/octave thatcorefile -ex 'thread apply all bt full' -ex 'info thread' -ex 'info shared' -ex q
also says the backtrace without uploads; but backtrace is sometimes not enough; and core dump is sometimes also not enough; but still better than nothing.

Jan Kratochvil <lace>
Mon 18 Oct 2010 03:40:29 PM UTC, comment #12: 

I don't think the core file from your system is going to help me.  I recommend that you run Octave with gdb and post a backtrace showing where the crash is happening.

John W. Eaton <jwe>
Group administrator
Mon 18 Oct 2010 11:16:28 AM UTC, comment #11: 

The core is too big for attachment (~267 Mb), it can be found here

https://docs.google.com/leaf?id=0B6QFUBFqR7nnODg5NjU4MGUtNjBlZi00NzI0LTk4YmEtZWVhMmE1NGU3NDc5&hl=en

John Hunt <huntj>
Mon 18 Oct 2010 09:42:38 AM UTC, comment #10: 

Another clue: the crash is happening on two different core i7.

To remove the -O2 flag, here are the building steps used :
in octave-3.3.52
make distclean
CFLAGS="-g" CXXFLAGS="-g" BUILD_CFLAGS="-g" BUILD_CXXFLAGS="-g" FFLAGS="-g" ./configure --with-blas=/usr/local/share/GotoBLAS2/libgoto2.so
make
make install

Then the procedure brought a crash at the first attempt :
$ octave
Segmentation fault

issuing
$ ulimit -c unlimited

and starting the procedure again yielded at step 10)
$ octave
Segmentation fault (core dumped)
(core file attached)

$ which octave
/usr/local/bin/octave
$ ldd /usr/local/bin/octave
        linux-vdso.so.1 =>  (0x00007fff10bff000)
        /usr/local/share/GotoBLAS2/libgoto2.so (0x00007fe8c8300000)
        liboctinterp-3.3.52.so => /usr/local/lib/octave-3.3.52/liboctinterp-3.3.52.so (0x00007fe8c718c000)
        liboctave-3.3.52.so => /usr/local/lib/octave-3.3.52/liboctave-3.3.52.so (0x00007fe8c62ab000)
        libcruft-3.3.52.so => /usr/local/lib/octave-3.3.52/libcruft-3.3.52.so (0x00007fe8c5fe6000)
        libfftw3.so.3 => /usr/local/lib/libfftw3.so.3 (0x00007fe8c5ce0000)
        libfftw3f.so.3 => /usr/local/lib/libfftw3f.so.3 (0x00007fe8c59e1000)
        libfltk_gl.so.1.1 => /usr/lib64/libfltk_gl.so.1.1 (0x00007fe8c57c4000)
        libfltk.so.1.1 => /usr/lib64/libfltk.so.1.1 (0x00007fe8c5515000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe8c52f8000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fe8c50e5000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fe8c4e5c000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fe8c4c46000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fe8c4a0f000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fe8c4799000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007fe8c452a000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fe8c41ea000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fe8c3fa3000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fe8c3d4e000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fe8c3b20000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fe8c391c000)
        libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007fe8c3636000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe8c33df000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe8c307f000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe8c2d75000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe8c2b5f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe8c8fba000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fe8c2935000)
        libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fe8c272f000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fe8c252c000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fe8c2326000)
        libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fe8c211a000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fe8c1efd000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fe8c1cf4000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fe8c1af0000)


John Hunt <huntj>
Sun 17 Oct 2010 12:14:29 AM UTC, comment #9: 

I do not have it reproducible even on installed OpenSUSE 11.3, 64bits.

> Sometimes it does not crash (due to a different initial state
> ?),


That's the problem, it probably depends on specific memory layout given by kernel which is more a luck.

If you have it sometimes reproducible you should provide a core file (ulimit -c unlimited; ./octave) with all the referenced binaries/libraries, octave best compiled with "-g" (that is without "-O2").  Thanks.

Jan Kratochvil <lace>
Fri 15 Oct 2010 09:20:46 AM UTC, comment #8: 

On the web page spaces have been stripped from comment #7
https://savannah.gnu.org/bugs/index.php?30478#comment7
making the procedure unreadable
here it is in another form

in terminals A and B, type
1) A: octave
2) A: exit
3) A: octave
4) A: exit
5) A: octave
6) B: octave
7) A: exit
8) B: exit
9) A: octave
10) B: octave=>Segmentation fault

John Hunt <huntj>
Fri 15 Oct 2010 09:06:19 AM UTC, comment #7: 

Related reproducible crash, with octave 3.2.4, 3.3.52 and
3.3.52+ development version
(hg clone http://www.octave.org/hg/octave)

on OpenSUSE 11.3, 64bits
uname -a :
Linux xxxx 2.6.34.7-0.3-desktop #1 SMP PREEMPT 2010-09-20 15:27:38 +0200 x86_64 x86_64 x86_64 GNU/Linux


removing preload functionnality
sudo zypper rm preload
and the crash disappeared

bringing it back
sudo zypper install preload
and the crash is back also


Procedure to generate the crash (order matters):
open two terminals, and type

    Terminal 1                Terminal 2
1)  octave
2)  exit
3)  octave
4)  exit
5)  octave
6)                              octave
7)  exit
8)                              exit
9)  octave
10)                             octave=>Segmentation fault

the crash looks like that:
$ octave
Segmentation fault
$

Sometimes it does not crash (due to a different initial state ?),
but after the first SegFault on terminal 2, just exit from octave
in terminal 1, and starting again the procedure the crash always
occurs, either always at step 6 or always at step 10 (again
depending on initial conditions ?)

At the identified crashing step,
replacing the command octave by gdb octave,
and typing run, gives no crash at all.




John Hunt <huntj>
Mon 19 Jul 2010 09:00:29 AM UTC, comment #6: 

The 3.2.x branch is essentially closed, no new 3.2.x releases are in preparation, despite the fact that 3.4.0 may still be months away. Not enough contributors :(

I'm not sure what constructs should be avoided to make prelinking possible (in fact I haven't heard of it before). But if someone sends patches to the 3.2.4 sources, I'm willing to invest some time into preparing a 3.2.5 release just for this particular purpose.


Jaroslav Hajek <highegg>
Mon 19 Jul 2010 08:28:22 AM UTC, comment #5: 

From
https://bugzilla.redhat.com/show_bug.cgi?id=524493#c1
https://bugzilla.redhat.com/show_bug.cgi?id=524493#c5
backtraces it crashes on:
   0x000000000046920e <+158>:   addl   $0x1,0xc(%rax)
liboctave/dim-vector.h:176
  explicit dim_vector (void)
    : rep (nil_rep ()) { rep->count++; }
                         ^^^^^^^^^^^^^

This is dereferencing symbol `dim_vector::nil_rep() const::nr':
liboctave/dim-vector.h:168
  dim_vector_rep *nil_rep (void) const
  {
    static dim_vector_rep *nr = new dim_vector_rep ();

    return nr;
  }

Unfortunately without a reproducer and limited info the backtrace I cannot say more.  But that `static' variable `nr' seems a bit needlessly risky there.  (It could be also gcc-overoptimized.)

HG change 9507 already changed this code due to other reasons so this bug may no longer be present there.  (octave-3.2.4-2.fc13 still does not contain this change, though.)

Jan Kratochvil <lace>
Mon 19 Jul 2010 08:13:29 AM UTC, comment #4: 

Sure, but prelinking isn't a random thing that a user does on his/her own for the fun of it.  It's a common system-wide background process that's run on most Linux distro, so it would be nice if we could find the bug, although I do appreciate it might be difficult to do so (hence our workaround of disabling prelinking for octave).

It seems to be OK on your Kubuntu prelinking which suggests that there is something in the interaction on Fedora that might be in octave, might be the prelinking package itself. or might be in one of the libraries we compile against.

As a user of octave it doesn't personally bother me too much if we exclude it from prelinking, but as the maintainer of the package, I've had requests to fix it so that prelinking works but I don't know enough about octave internals to do so, hence I'm forwarding it upstream.  If the conclusion from upstream is that it's not possible and that they need to live with it, then I can at least communicate that to our downstream users.

Alex Lancaster <alexl>
Mon 19 Jul 2010 07:05:55 AM UTC, comment #3: 

I agree that there is a problem, but I'm not sure that it can be localized to the Octave code base.  As one of the original reporter's noted, when they compiled from source the executable was fine.  From a developer perspective, that is as much as I take responsibility for -- I wrote code and it compiles cleanly and executes. 

If a user then re-arranges the internals of the code by pre-linking and it ceases to work, I don't feel terribly responsible for that.

It may help to look through a more detailed backtrace, but this kind of thing can be very difficult to debug since it could depend on a whole lot of libraries and the specific ways in which they were compiled.

Rik <rik5>
Group administrator
Mon 19 Jul 2010 06:02:15 AM UTC, comment #2: 

I'm pretty sure it's a real bug (I definitely saw it a few releases back), but I'll ask people to submit a full backtrace here.  It may be that kubuntu uses different versions of libraries to compile against which is why you don't see it there.  Do you have access to a Fedora machine?

Alex Lancaster <alexl>
Mon 19 Jul 2010 05:54:37 AM UTC, comment #1: 

I'm not sure this is an Octave bug.  It seems to be related more to the distribution and potential packaging.

At any rate, I cannot reproduce a crash with Octave versions 3.05, 3.23, 3.24, and the development version 3.3.51.

I am not running Fedora, however.  Details of my machine are:
Distribution: Kubuntu 9.04 amd64
Kernel: 2.6.31-22-generic
Prelink: 0.0.20090311-1ubuntu3
octave-3.0.5 installed from .debs
All other versions built from source and installed manually.

Unfortunately the user didn't have debugging libraries so the backtrace isn't very useful.

Rik <rik5>
Group administrator
Sun 18 Jul 2010 09:01:06 PM UTC, original submission:  

Originally reported in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=524493

Currently our package has to explicitly disable prelinking for octave because prelinked binaries cause crashes.  So we include

/etc/prelink.conf.d/octave.conf

with contents:

-b /usr/bin/octave-<version>

to disable prelinking, where <version> is the latest version, currently 3.2.4.  Ideally this workaround would not be necessary.

A backtrace is at:

https://bugzilla.redhat.com/attachment.cgi?id=361834

Alex Lancaster <alexl>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #21825:  backtrace added by huntj (12KiB - application/octet-stream)
file #21818:  backtrace_localbinoctave added by huntj (11KiB - application/octet-stream)
file #21819:  backtrace_strippedoctave added by huntj (13KiB - application/octet-stream)
file #21710:  backtrace added by huntj (12KiB - application/octet-stream - backtrace of comment #10)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by huntj (Posted a comment)
  • -email is unavailable- added by highegg (Posted a comment)
  • -email is unavailable- added by lace (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by alexl (Submitted the item)
  • -email is unavailable- added by alexl (Fedora developer)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-05 rik5 Open/ClosedOpen Closed
    2010-10-26 huntj Attached File- Added backtrace, #21825
    2010-10-25 huntj Attached File- Added backtrace_localbinoctave, #21818
        Attached File- Added backtrace_strippedoctave, #21819
    2010-10-18 huntj Attached File- Added backtrace, #21710
    2010-07-19 rik5 StatusNone Works For Me
    2010-07-18 alexl Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code