Bug 877128 - Ocaml tries to allocate a ridiculous amount of memory
Ocaml tries to allocate a ridiculous amount of memory
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ocaml (Show other bugs)
18
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
: Reopened
: 876765 884741 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-15 13:47 EST by Susi Lehtola
Modified: 2013-01-11 19:50 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 445545
Environment:
Last Closed: 2013-01-11 19:50:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace of the F18 binary (41.53 KB, application/octet-stream)
2012-11-15 14:59 EST, Susi Lehtola
no flags Details
strace of the F17 binary (40.94 KB, application/octet-stream)
2012-11-15 15:03 EST, Susi Lehtola
no flags Details
gdb backtrace of failing brk() (7.11 KB, text/plain)
2012-12-02 09:36 EST, Volker Braun
no flags Details
ocaml r12907 (7.16 KB, patch)
2012-12-13 11:11 EST, Richard W.M. Jones
no flags Details | Diff

  None (edit)
Description Susi Lehtola 2012-11-15 13:47:00 EST
Looks like the old memory allocation bug in Ocaml is back on Fedora 18 x86_64.

Running the F18 x86_64 build of Unison
http://koji.fedoraproject.org/koji/taskinfo?taskID=4692447

ends up with

$ unison
Fatal error: out of memory.

Strace reveals
mmap(NULL, 259407338535944192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)

so there is something seriously wrong in the compiler. The same RPM compiled on F17 works fine in F18.
Comment 1 Richard W.M. Jones 2012-11-15 13:57:29 EST
Re the last sentence: *unison* compiled with OCaml < 4.00.0 works OK?

I don't see anything in the changelog of 4.00.1 which would
address this bug.

Can you get a stack trace of the unison binary at the point
where it crashes?

Also I will ask on the upstream mailing lits.
Comment 2 Susi Lehtola 2012-11-15 14:55:01 EST
Yup, the F17 build of unison used ocaml-3.12.1-12.fc17.x86_64 whereas the F18 build is with ocaml-4.00.0-1.fc18.x86_64. The F17 build works but the F18 build doesn't.
Comment 3 Susi Lehtola 2012-11-15 14:59:29 EST
Created attachment 645910 [details]
strace of the F18 binary
Comment 4 Susi Lehtola 2012-11-15 15:03:56 EST
Created attachment 645911 [details]
strace of the F17 binary
Comment 5 Richard W.M. Jones 2012-11-15 16:43:19 EST
I really mean a stack trace, not system call trace:
https://fedoraproject.org/wiki/StackTraces
Comment 6 Susi Lehtola 2012-11-15 16:59:12 EST
Right.

But not much help there:

$ gdb unison-2.40
GNU gdb (GDB) Fedora (7.5.0.20120926-25.fc18)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/unison-2.40...Reading symbols from /usr/lib/debug/usr/bin/unison-2.40.debug...done.
done.
(gdb) r
Starting program: /usr/bin/unison-2.40 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info
Fatal error: out of memory.
[Inferior 1 (process 29192) exited with code 02]
(gdb)
Comment 7 Volker Braun 2012-12-02 09:36:19 EST
Created attachment 656039 [details]
gdb backtrace of failing brk()

I set a breakpoint at the failing brk() call to get a backtrace at the point where things go south. Though all I can see is that its somewhere in the bowels of the ocaml interpreter.
Comment 8 Volker Braun 2012-12-02 09:48:16 EST
This is the upstream bug report: http://caml.inria.fr/mantis/view.php?id=5717
Comment 9 kpijarski 2012-12-08 05:21:29 EST
I am experiencing the same problem in F18 beta - the same version (2.40) on F17 works without problems. What is more, the lesser version of unison (2.27) does work! How can this be if it is built against the same library, or is it not?

At the same time, when trying to sync my computers with 2.27 for the time being the comparison process always spits out that both databases are different and that I should compare again. Needless to say, it doesn't work.
Comment 10 kpijarski 2012-12-08 05:22:13 EST
btw, why is the platform set to "arm Linux" ?
Comment 11 Volker Braun 2012-12-08 06:05:05 EST
Seems like only x86_64 is affected, at least thats where all reports on this ticket are from. Somebody with sufficient permissions should change the platform.

A workaround for unison is to copy /usr/bin/unison-2.40 from Fedora 17 over to the Fedora 18 install.
Comment 12 Jerry James 2012-12-11 16:54:17 EST
I'm having the same problem (out of memory with a ridiculously large allocation attempt) in coqide (package name is coq-coqide).  As noted above, this only seems to affect F-18 x86_64.  It works fine in Rawhide.  See bug 884741.
Comment 13 Richard W.M. Jones 2012-12-11 17:20:25 EST
(In reply to comment #12)
> As noted above,
> this only seems to affect F-18 x86_64.  It works fine in Rawhide.  See bug
> 884741.

When I looked at the list of changes from 4.00.0 -> 4.00.1
(ie. F18 -> Rawhide) I did not see anything that looked like
it should fix this bug.  Also I've seen this sort of thing
before with data-driven changes to the GC causing a bug to
appear and disappear seemingly at random.  So I'd be very
careful about saying that Rawhide (4.00.1) would be a
fix for this bug.  Not until we understand why precisely
the bug happens in F18.
Comment 14 Richard W.M. Jones 2012-12-11 17:21:26 EST
And I'd still like to see a stack trace of the problem
when the bug occurs (comment 1).
Comment 15 Jerry James 2012-12-11 17:29:30 EST
(In reply to comment #13)
> When I looked at the list of changes from 4.00.0 -> 4.00.1
> (ie. F18 -> Rawhide) I did not see anything that looked like
> it should fix this bug.  Also I've seen this sort of thing
> before with data-driven changes to the GC causing a bug to
> appear and disappear seemingly at random.  So I'd be very
> careful about saying that Rawhide (4.00.1) would be a
> fix for this bug.  Not until we understand why precisely
> the bug happens in F18.

Sure.  Let me try that again.

I have tried running coqide on a Fedora 18 x86_64 VM numerous times.  In all of those attempts, it never managed to map a window before failing due to this bug.  I have tried running coqide on a Fedora Rawhide x86_64 VM several times.  On each attempt, coqide mapped its window and let me do some simple proofs without manifesting this bug.

(In reply to comment #14)
> And I'd still like to see a stack trace of the problem
> when the bug occurs (comment 1).

An attempt I made just now produced essentially the same backtrace as the one shown in the bug report linked from comment 8.  What can I do to get a more informative stack trace for you?
Comment 16 Richard W.M. Jones 2012-12-11 17:40:05 EST
(In reply to comment #15)
> I have tried running coqide on a Fedora 18 x86_64 VM numerous times.  In all
> of those attempts, it never managed to map a window before failing due to
> this bug.  I have tried running coqide on a Fedora Rawhide x86_64 VM several
> times.  On each attempt, coqide mapped its window and let me do some simple
> proofs without manifesting this bug.

I don't doubt you.

The problem this could be caused by two things:

(1) The Coq codepath just doesn't cause the GC to hit this bug on Rawhide.

(2) The bug is fixed -- but if so, what patch in .1 fixed it?

I really don't know if it's (1) or (2).

> (In reply to comment #14)
> > And I'd still like to see a stack trace of the problem
> > when the bug occurs (comment 1).
> 
> An attempt I made just now produced essentially the same backtrace as the
> one shown in the bug report linked from comment 8.  What can I do to get a
> more informative stack trace for you?

One with ocaml-debuginfo (plus deps) would be a lot more helpful.
Comment 17 Evan Nemerson 2012-12-11 18:24:15 EST
> > (In reply to comment #14)
> > > And I'd still like to see a stack trace of the problem
> > > when the bug occurs (comment 1).
> > 
> > An attempt I made just now produced essentially the same backtrace as the
> > one shown in the bug report linked from comment 8.  What can I do to get a
> > more informative stack trace for you?
> 
> One with ocaml-debuginfo (plus deps) would be a lot more helpful.

Installing ocaml-debuginfo doesn't seem to do much good:


$ rpm -q ocaml-debuginfo
ocaml-debuginfo-4.00.0-1.fc18.x86_64
$ gdb -ex run --args unison Documents -ui text
GNU gdb (GDB) Fedora (7.5.1-31.fc18)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/unison...Reading symbols from /usr/lib/debug/usr/bin/unison-2.40.debug...done.
done.
Starting program: /usr/bin/unison Documents -ui text
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info
Fatal error: out of memory.
[Inferior 1 (process 20576) exited with code 02]
(gdb) quit


Is there anything else we can do?  I have a feeling this is one of those issues where something with lower latency than bugzilla might be easier...  If you want to meet up on IRC I'd be happy to help get whatever info you need.  I'm nemequ on freenode and gimpnet.
Comment 18 Jerry James 2012-12-12 18:29:52 EST
Ditto that.  After installing ocaml-debuginfo, the stack trace still looks like the one linked from comment 8, up through frame 8 (caml_system__code_begin).

So I built my own ocaml binaries from the git sources, and callously overwrote the system versions with binaries and libraries containing debug symbols, then did the same for coq.  Ugh.  Anyway, try this stack trace:

#0  __GI__IO_fputs (str=str@entry=0x6860ec "Fatal error: out of memory.\n", fp=
    0x3725fb21a0 <_IO_2_1_stderr_>) at iofputs.c:35
#1  0x000000000066cdc0 in fprintf (__fmt=<optimized out>,
    __stream=<optimized out>) at /usr/include/bits/stdio2.h:97
#2  caml_fatal_error (msg=msg@entry=0x6860ec "Fatal error: out of memory.\n")
    at misc.c:54
#3  0x000000000066f874 in caml_alloc_shr (wosize=wosize@entry=
    18014398509439783, tag=<optimized out>) at memory.c:416
#4  0x000000000066e9bf in caml_oldify_one (v=140737353766824, p=0x9b2fa0)
    at minor_gc.c:130
#5  0x000000000066bad7 in caml_oldify_local_roots () at roots.c:168
#6  0x000000000066ebd5 in caml_empty_minor_heap () at minor_gc.c:234
#7  0x000000000066ed1d in caml_minor_collection () at minor_gc.c:277
#8  0x000000000066cc1a in caml_garbage_collection () at signals_asm.c:71
#9  0x000000000067e128 in caml_system__code_begin ()
#10 0x0000000000615735 in camlMap__add_1082 () at map.ml:114
#11 0x00000000006156d4 in camlMap__add_1082 () at map.ml:114
#12 0x00000000006156d4 in camlMap__add_1082 () at map.ml:114
#13 0x00000000006356ec in camlCamlinternalOO__fun_1593 ()
    at camlinternalOO.ml:219
#14 0x000000000060f232 in camlList__iter2_1106 () at list.ml:112
#15 0x00000000006368f3 in camlCamlinternalOO__narrow_1161 ()
    at camlinternalOO.ml:215
#16 0x000000000063713a in camlCamlinternalOO__inherits_1233 ()
    at camlinternalOO.ml:320
#17 0x00000000005bd85c in camlGButton__tool_item_skel_init_3064 ()
#18 0x00007ffff7e3af20 in ?? ()
...
[followed by nonsense stack frames with addresses like 0x25].

In frame 4, sz = 18014398509439783, and all other locals = <optimized out>.  Don't you hate that?  So let's figure it out for ourselves from the value of v, and these definitions in stdlib/caml/mlvalues.h:

#define Tag_hd(hd) ((tag_t) ((hd) & 0xFF))
#define Wosize_hd(hd) ((mlsize_t) ((hd) >> 10))
#define Hd_val(val) (((header_t *) (val)) [-1])

which gives us the following variable values (with a little help from GDB):

hd = 18446744073666338135
tag = 87
sz = 18014398509439783

In frame 5, the only local variables that are not <optimized out> are i = 88 and j = 11.  The value of glob = caml_globals[i] is 10170184, which means that the failing call was:

Oldify (&Field (10170184, 11));   ==>
Oldify (&(((value *)(10170184)) [11]));  ==>
Oldify ((value *) 0x9b2fa0);  ==>
do {
  value __oldify__v__ = *(value *)0x9b2fa0;
  if (Is_block (__oldify__v__) && Is_young (__oldify__v__)){
    caml_oldify_one (__oldify__v__, (value *)0x9b2fa0);
  }
} while(0);

And *(value *)0x9b2fa0 == 140737353766824, for the record.  I don't actually understand much, if any, of this, so tell me what else you want GDB to reveal.
Comment 19 Gregor Tätzner 2012-12-13 09:46:58 EST
(In reply to comment #13)
> (In reply to comment #12)
> > As noted above,
> > this only seems to affect F-18 x86_64.  It works fine in Rawhide.  See bug
> > 884741.
> 
> When I looked at the list of changes from 4.00.0 -> 4.00.1
> (ie. F18 -> Rawhide) I did not see anything that looked like
> it should fix this bug.  Also I've seen this sort of thing
> before with data-driven changes to the GC causing a bug to
> appear and disappear seemingly at random.  So I'd be very
> careful about saying that Rawhide (4.00.1) would be a
> fix for this bug.  Not until we understand why precisely
> the bug happens in F18.

On a side note: the rawhide(fc19) build of unison240 seems to work fine on F-18 x86_64, too.
Comment 20 Volker Braun 2012-12-13 10:00:41 EST
The OCaml 4.00.0 -> 4.00.1 changelog lists a serious bug fix for the x86_64 code generator:

- PR#5707: AMD64 code generator: do not use r10 and r11 for parameter passing,
  as these registers can be destroyed by the dynamic loader

http://caml.inria.fr/pub/distrib/ocaml-4.00/notes/Changes

I think its pretty clear that we are being hit by this. This also explains why the rawhide version of OCaml-4.00.1 works.
Comment 21 Richard W.M. Jones 2012-12-13 10:51:12 EST
That is indeed a very serious bug that could cause this
sort of error easily.  Not sure why I didn't spot that before ...

Let me backport just that fix to F18 and see if that improves the
situation.
Comment 22 Richard W.M. Jones 2012-12-13 11:11:26 EST
Created attachment 663037 [details]
ocaml r12907

(In reply to comment #21)
> That is indeed a very serious bug that could cause this
> sort of error easily.  Not sure why I didn't spot that before ...
> 
> Let me backport just that fix to F18 and see if that improves the
> situation.

Dammit, unfortunately this makes the calling convention
incompatible, so all packages would have to be recompiled
anyway.  In which case we might as well just update to 4.00.1
from Rawhide.  This is a huge chunk of work.

Attached is the patch which would fix the register problem.
Comment 23 Richard W.M. Jones 2012-12-13 11:16:42 EST
For better or worse, I started to rebuild the F18 packages.
This is going to take a while.
Comment 24 Jerry James 2012-12-13 11:21:53 EST
If you'll let us know when the new ocaml package is available as a buildroot override, I'll rebuild the ocaml packages that I rebuilt for the Rawhide update (packages I maintain, plus a few dependencies).
Comment 25 Jerry James 2012-12-13 11:23:00 EST
*** Bug 884741 has been marked as a duplicate of this bug. ***
Comment 26 Fedora Update System 2012-12-13 12:05:23 EST
ocaml-4.00.1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ocaml-4.00.1-1.fc18
Comment 27 Richard W.M. Jones 2012-12-13 12:30:17 EST
(In reply to comment #24)
> If you'll let us know when the new ocaml package is available as a buildroot
> override, I'll rebuild the ocaml packages that I rebuilt for the Rawhide
> update (packages I maintain, plus a few dependencies).

ocaml-4.00.1-1.fc18 and ocaml-findlib-1.3.3-3.fc18 are now
available as buildroot overrides to build against.
Comment 28 Fedora Update System 2012-12-14 01:47:15 EST
Package ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ocaml-4.00.1-1.fc18 ocaml-findlib-1.3.3-3.fc18 ocaml-camlidl-1.05-17.fc18 ocaml-camlp5-6.07-1.fc18 ocaml-lablgl-20120306-4.fc18 ocaml-lablgtk-2.16.0-1.fc18 xen-4.2.0-7.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20337/xen-4.2.0-7.fc18,ocaml-lablgtk-2.16.0-1.fc18,ocaml-lablgl-20120306-4.fc18,ocaml-camlp5-6.07-1.fc18,ocaml-camlidl-1.05-17.fc18,ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18
then log in and leave karma (feedback).
Comment 29 Gregor Tätzner 2012-12-14 09:40:35 EST
*** Bug 876765 has been marked as a duplicate of this bug. ***
Comment 30 Fedora Update System 2012-12-14 18:20:43 EST
Package ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18, zenon-0.7.1-3.fc18, ocaml-zarith-1.1-3.fc18, ocaml-ocamlgraph-1.8.2-2.fc18, ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18, ocaml-menhir-20120123-5.fc18, gappalib-coq-0.18.0-5.fc18, coq-8.4-3.fc18, apron-0.9.10-9.fc18, alt-ergo-0.94-7.fc18, ocaml-ancient-0.9.0-10.fc18, ocaml-bisect-1.1-4.fc18, ocaml-augeas-0.5-3.fc18, ocaml-cil-1.4.0-6.fc18, ocaml-camomile-0.8.3-10.fc18, ocaml-extlib-1.5.3-2.fc18, ocaml-camlimages-4.0.1-7.fc18, ocaml-calendar-2.03.2-2.fc18, ocaml-cairo-1.2.0-0.8.git08b40192975.fc18, ocaml-bitstring-2.0.3-5.fc18, ocaml-curl-0.5.3-7.fc18, ocaml-cryptokit-1.6-3.fc18, ocaml-curses-1.0.3-15.fc18, ocaml-deriving-0.1.1a-17.fc18, ocaml-dbus-0.29-6.fc18, ocaml-expat-0.9.1-24.fc18, ocaml-facile-1.1-19.fc18, ocaml-csv-1.2.3-3.fc18, ocaml-libvirt-0.6.1.2-6.fc18, ocaml-newt-0.9-14.fc18, ocaml-mysql-1.1.1-1.fc18, ocaml-gsl-0.6.0-16.fc18, ocaml-lacaml-7.0.3-1.fc18, ocaml-json-static-0.9.8-8.fc18, ocaml-pa-do-0.8.15-1.fc18, ocaml-perl4caml-0.9.5-23.fc18, ocaml-ounit-1.1.2-4.fc18, ocaml-ssl-0.4.6-5.fc18, ocaml-pcre-7.0.2-2.fc18, ocaml-ulex-1.1-15.fc18, ocaml-openin-20070524-16.fc18, ocaml-sqlite-1.6.3-3.fc18, ocaml-xml-light-2.3-0.3.svn234.fc18, ocaml-zip-1.04-10.fc18, ocaml-type-conv-3.0.5-3.fc18, ocaml-p3l-2.03-12.fc18, ocaml-react-0.9.4-1.fc18, ocaml-res-3.2.0-10.fc18, ocaml-pa-monad-6.0-10.fc18, ocaml-postgresql-2.0.2-1.fc18, ocaml-SDL-0.8.0-7.fc18, ocaml-sexplib-7.0.5-4.fc18, ocaml-lwt-2.4.2-1.fc18, ocaml-reins-0.1a-14.fc18, ocaml-bin-prot-2.0.9-3.fc18, ocaml-ocamlnet-3.5.1-4.fc18, ocaml-fileutils-0.4.4-4.fc18, ocaml-pgocaml-1.6-2.fc18, ocaml-gettext-0.3.4-8.fc18, ocaml-xmlrpc-light-0.6.1-11.fc18, ocaml-pxp-1.2.3-5.fc18, ocaml-json-wheel-1.0.6-10.fc18, ocaml-preludeml-0.1-0.22.20100314.fc18, frama-c-1.8-4.fc18, brltty-4.3-10.fc18, hivex-1.3.7-2.fc18, virt-top-1.0.8-3.fc18, virt-dmesg-0.3.0-6.fc18, whenjobs-0.7.3-4.fc18, coccinelle-1.0.0-0.rc14.6.fc18, js-of-ocaml-1.2-2.fc18, llvm-3.1-12.fc18, cduce-0.5.5-3.fc18, why3-0.73-3.fc18, graphviz-2.28.0-24.fc18, unison213-2.13.16-20.fc18, unison227-2.27.57-19.fc18, unison240-2.40.102-2.fc18, why-2.31-4.fc18, kalzium-4.9.4-2.fc18, plplot-5.9.9-12.svn12202.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ocaml-4.00.1-1.fc18 ocaml-findlib-1.3.3-3.fc18 ocaml-camlidl-1.05-17.fc18 ocaml-camlp5-6.07-1.fc18 ocaml-lablgl-20120306-4.fc18 ocaml-lablgtk-2.16.0-1.fc18 xen-4.2.0-7.fc18 zenon-0.7.1-3.fc18 ocaml-zarith-1.1-3.fc18 ocaml-ocamlgraph-1.8.2-2.fc18 ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18 ocaml-menhir-20120123-5.fc18 gappalib-coq-0.18.0-5.fc18 coq-8.4-3.fc18 apron-0.9.10-9.fc18 alt-ergo-0.94-7.fc18 ocaml-ancient-0.9.0-10.fc18 ocaml-bisect-1.1-4.fc18 ocaml-augeas-0.5-3.fc18 ocaml-cil-1.4.0-6.fc18 ocaml-camomile-0.8.3-10.fc18 ocaml-extlib-1.5.3-2.fc18 ocaml-camlimages-4.0.1-7.fc18 ocaml-calendar-2.03.2-2.fc18 ocaml-cairo-1.2.0-0.8.git08b40192975.fc18 ocaml-bitstring-2.0.3-5.fc18 ocaml-curl-0.5.3-7.fc18 ocaml-cryptokit-1.6-3.fc18 ocaml-curses-1.0.3-15.fc18 ocaml-deriving-0.1.1a-17.fc18 ocaml-dbus-0.29-6.fc18 ocaml-expat-0.9.1-24.fc18 ocaml-facile-1.1-19.fc18 ocaml-csv-1.2.3-3.fc18 ocaml-libvirt-0.6.1.2-6.fc18 ocaml-newt-0.9-14.fc18 ocaml-mysql-1.1.1-1.fc18 ocaml-gsl-0.6.0-16.fc18 ocaml-lacaml-7.0.3-1.fc18 ocaml-json-static-0.9.8-8.fc18 ocaml-pa-do-0.8.15-1.fc18 ocaml-perl4caml-0.9.5-23.fc18 ocaml-ounit-1.1.2-4.fc18 ocaml-ssl-0.4.6-5.fc18 ocaml-pcre-7.0.2-2.fc18 ocaml-ulex-1.1-15.fc18 ocaml-openin-20070524-16.fc18 ocaml-sqlite-1.6.3-3.fc18 ocaml-xml-light-2.3-0.3.svn234.fc18 ocaml-zip-1.04-10.fc18 ocaml-type-conv-3.0.5-3.fc18 ocaml-p3l-2.03-12.fc18 ocaml-react-0.9.4-1.fc18 ocaml-res-3.2.0-10.fc18 ocaml-pa-monad-6.0-10.fc18 ocaml-postgresql-2.0.2-1.fc18 ocaml-SDL-0.8.0-7.fc18 ocaml-sexplib-7.0.5-4.fc18 ocaml-lwt-2.4.2-1.fc18 ocaml-reins-0.1a-14.fc18 ocaml-bin-prot-2.0.9-3.fc18 ocaml-ocamlnet-3.5.1-4.fc18 ocaml-fileutils-0.4.4-4.fc18 ocaml-pgocaml-1.6-2.fc18 ocaml-gettext-0.3.4-8.fc18 ocaml-xmlrpc-light-0.6.1-11.fc18 ocaml-pxp-1.2.3-5.fc18 ocaml-json-wheel-1.0.6-10.fc18 ocaml-preludeml-0.1-0.22.20100314.fc18 frama-c-1.8-4.fc18 brltty-4.3-10.fc18 hivex-1.3.7-2.fc18 virt-top-1.0.8-3.fc18 virt-dmesg-0.3.0-6.fc18 whenjobs-0.7.3-4.fc18 coccinelle-1.0.0-0.rc14.6.fc18 js-of-ocaml-1.2-2.fc18 llvm-3.1-12.fc18 cduce-0.5.5-3.fc18 why3-0.73-3.fc18 graphviz-2.28.0-24.fc18 unison213-2.13.16-20.fc18 unison227-2.27.57-19.fc18 unison240-2.40.102-2.fc18 why-2.31-4.fc18 kalzium-4.9.4-2.fc18 plplot-5.9.9-12.svn12202.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20337/plplot-5.9.9-12.svn12202.fc18,kalzium-4.9.4-2.fc18,why-2.31-4.fc18,unison213-2.13.16-20.fc18,unison227-2.27.57-19.fc18,unison240-2.40.102-2.fc18,llvm-3.1-12.fc18,cduce-0.5.5-3.fc18,why3-0.73-3.fc18,graphviz-2.28.0-24.fc18,frama-c-1.8-4.fc18,brltty-4.3-10.fc18,hivex-1.3.7-2.fc18,virt-top-1.0.8-3.fc18,virt-dmesg-0.3.0-6.fc18,whenjobs-0.7.3-4.fc18,coccinelle-1.0.0-0.rc14.6.fc18,js-of-ocaml-1.2-2.fc18,ocaml-preludeml-0.1-0.22.20100314.fc18,ocaml-gettext-0.3.4-8.fc18,ocaml-xmlrpc-light-0.6.1-11.fc18,ocaml-pxp-1.2.3-5.fc18,ocaml-json-wheel-1.0.6-10.fc18,ocaml-sexplib-7.0.5-4.fc18,ocaml-lwt-2.4.2-1.fc18,ocaml-reins-0.1a-14.fc18,ocaml-bin-prot-2.0.9-3.fc18,ocaml-ocamlnet-3.5.1-4.fc18,ocaml-fileutils-0.4.4-4.fc18,ocaml-pgocaml-1.6-2.fc18,ocaml-pa-do-0.8.15-1.fc18,ocaml-perl4caml-0.9.5-23.fc18,ocaml-ounit-1.1.2-4.fc18,ocaml-ssl-0.4.6-5.fc18,ocaml-pcre-7.0.2-2.fc18,ocaml-ulex-1.1-15.fc18,ocaml-openin-20070524-16.fc18,ocaml-sqlite-1.6.3-3.fc18,ocaml-xml-light-2.3-0.3.svn234.fc18,ocaml-zip-1.04-10.fc18,ocaml-type-conv-3.0.5-3.fc18,ocaml-p3l-2.03-12.fc18,ocaml-react-0.9.4-1.fc18,ocaml-res-3.2.0-10.fc18,ocaml-pa-monad-6.0-10.fc18,ocaml-postgresql-2.0.2-1.fc18,ocaml-SDL-0.8.0-7.fc18,ocaml-csv-1.2.3-3.fc18,ocaml-libvirt-0.6.1.2-6.fc18,ocaml-newt-0.9-14.fc18,ocaml-mysql-1.1.1-1.fc18,ocaml-gsl-0.6.0-16.fc18,ocaml-lacaml-7.0.3-1.fc18,ocaml-json-static-0.9.8-8.fc18,ocaml-curl-0.5.3-7.fc18,ocaml-cryptokit-1.6-3.fc18,ocaml-curses-1.0.3-15.fc18,ocaml-deriving-0.1.1a-17.fc18,ocaml-dbus-0.29-6.fc18,ocaml-expat-0.9.1-24.fc18,ocaml-facile-1.1-19.fc18,ocaml-cil-1.4.0-6.fc18,ocaml-camomile-0.8.3-10.fc18,ocaml-extlib-1.5.3-2.fc18,ocaml-camlimages-4.0.1-7.fc18,ocaml-calendar-2.03.2-2.fc18,ocaml-cairo-1.2.0-0.8.git08b40192975.fc18,ocaml-bitstring-2.0.3-5.fc18,ocaml-bisect-1.1-4.fc18,ocaml-augeas-0.5-3.fc18,ocaml-ancient-0.9.0-10.fc18,zenon-0.7.1-3.fc18,ocaml-zarith-1.1-3.fc18,ocaml-ocamlgraph-1.8.2-2.fc18,ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18,ocaml-menhir-20120123-5.fc18,gappalib-coq-0.18.0-5.fc18,coq-8.4-3.fc18,apron-0.9.10-9.fc18,alt-ergo-0.94-7.fc18,xen-4.2.0-7.fc18,ocaml-lablgtk-2.16.0-1.fc18,ocaml-lablgl-20120306-4.fc18,ocaml-camlp5-6.07-1.fc18,ocaml-camlidl-1.05-17.fc18,ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18
then log in and leave karma (feedback).
Comment 31 Adam Williamson 2012-12-17 14:50:13 EST
Proper NTH nomination.
Comment 32 Adam Williamson 2012-12-17 15:06:29 EST
Discussed at 2012-12-17 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Though this is a Big Hairy Emergency, on careful examination, we see no reasoning in the bug or ML thread as to why we actually have to break freeze for this. No impact on critical path or release blocking stuff has been demonstrated in this bug report or on the mailing list thread.

Does someone have a good reason as to why we have to break freeze and take this major change? Or is it OK for it to go out as a 0-day update?
Comment 33 Richard W.M. Jones 2012-12-17 15:58:14 EST
No reason to break any freeze.
Comment 34 Adam Williamson 2012-12-17 17:48:51 EST
On that basis I'm 'un-nominating' this rather than rejecting it: if rwmj doesn't think it needs to break freeze, no purpose to having it nominated.
Comment 35 Fedora Update System 2013-01-11 19:50:29 EST
ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18, zenon-0.7.1-3.fc18, ocaml-zarith-1.1-3.fc18, ocaml-ocamlgraph-1.8.2-2.fc18, ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18, ocaml-menhir-20120123-5.fc18, gappalib-coq-0.18.0-5.fc18, coq-8.4-3.fc18, apron-0.9.10-9.fc18, alt-ergo-0.94-7.fc18, ocaml-ancient-0.9.0-10.fc18, ocaml-bisect-1.1-4.fc18, ocaml-augeas-0.5-3.fc18, ocaml-cil-1.4.0-6.fc18, ocaml-camomile-0.8.3-10.fc18, ocaml-extlib-1.5.3-2.fc18, ocaml-camlimages-4.0.1-7.fc18, ocaml-calendar-2.03.2-2.fc18, ocaml-cairo-1.2.0-0.8.git08b40192975.fc18, ocaml-bitstring-2.0.3-5.fc18, ocaml-curl-0.5.3-7.fc18, ocaml-cryptokit-1.6-3.fc18, ocaml-curses-1.0.3-15.fc18, ocaml-deriving-0.1.1a-17.fc18, ocaml-dbus-0.29-6.fc18, ocaml-expat-0.9.1-24.fc18, ocaml-facile-1.1-19.fc18, ocaml-csv-1.2.3-3.fc18, ocaml-libvirt-0.6.1.2-6.fc18, ocaml-newt-0.9-14.fc18, ocaml-mysql-1.1.1-1.fc18, ocaml-gsl-0.6.0-16.fc18, ocaml-lacaml-7.0.3-1.fc18, ocaml-json-static-0.9.8-8.fc18, ocaml-pa-do-0.8.15-1.fc18, ocaml-perl4caml-0.9.5-23.fc18, ocaml-ounit-1.1.2-4.fc18, ocaml-ssl-0.4.6-5.fc18, ocaml-pcre-7.0.2-2.fc18, ocaml-ulex-1.1-15.fc18, ocaml-openin-20070524-16.fc18, ocaml-sqlite-1.6.3-3.fc18, ocaml-xml-light-2.3-0.3.svn234.fc18, ocaml-zip-1.04-10.fc18, ocaml-type-conv-3.0.5-3.fc18, ocaml-p3l-2.03-12.fc18, ocaml-react-0.9.4-1.fc18, ocaml-res-3.2.0-10.fc18, ocaml-pa-monad-6.0-10.fc18, ocaml-postgresql-2.0.2-1.fc18, ocaml-SDL-0.8.0-7.fc18, ocaml-sexplib-7.0.5-4.fc18, ocaml-lwt-2.4.2-1.fc18, ocaml-reins-0.1a-14.fc18, ocaml-bin-prot-2.0.9-3.fc18, ocaml-ocamlnet-3.5.1-4.fc18, ocaml-fileutils-0.4.4-4.fc18, ocaml-pgocaml-1.6-2.fc18, ocaml-gettext-0.3.4-8.fc18, ocaml-xmlrpc-light-0.6.1-11.fc18, ocaml-pxp-1.2.3-5.fc18, ocaml-json-wheel-1.0.6-10.fc18, ocaml-preludeml-0.1-0.22.20100314.fc18, frama-c-1.8-4.fc18, brltty-4.3-10.fc18, hivex-1.3.7-2.fc18, virt-top-1.0.8-3.fc18, virt-dmesg-0.3.0-6.fc18, whenjobs-0.7.3-4.fc18, coccinelle-1.0.0-0.rc14.6.fc18, js-of-ocaml-1.2-2.fc18, llvm-3.1-12.fc18, cduce-0.5.5-3.fc18, why3-0.73-3.fc18, graphviz-2.28.0-24.fc18, unison213-2.13.16-20.fc18, unison227-2.27.57-19.fc18, unison240-2.40.102-2.fc18, why-2.31-4.fc18, kalzium-4.9.4-2.fc18, plplot-5.9.9-12.svn12202.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.