[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#595921: marked as done (Future unblock: frama-c/20100401+boron+dfsg-5)

Your message dated Tue, 05 Oct 2010 19:38:10 +0100
with message-id <1286303890.30627.3.camel@hathi.jungle.funky-badger.org>
and subject line Re: Bug#595921: Future unblock: frama-c/20100401+boron+dfsg-5
has caused the Debian Bug report #595921,
regarding Future unblock: frama-c/20100401+boron+dfsg-5
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
595921: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595921
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: freeze-exception

Hi release team,

I received a tiny patch from upstream which fixes a performance bug
that could lead to a "stack overflow" error (a crash) during large
analyses. The patch is as follows:

Index: src/value/kf_state.ml
===================================================================
--- src/value/kf_state.ml	(revision 9760)
+++ src/value/kf_state.ml	(revision 9761)
@@ -44,7 +44,8 @@
        try Value.is_accessible (Kstmt (Kernel_function.find_first_stmt kf))
        with Kernel_function.No_Statement -> false)

-let mark_as_called kf = Is_Called.add kf true
+let mark_as_called kf = Is_Called.replace kf true

 (* ************************************************************************* *)
 (** {2 Callers} *)

There is no bug report for this issue (yet) since I got the patch
directly from upstream.

Would it be ok for upload an updated Frama-C package with this change
only?  Uploading a new Frama-C would require rebuilding Why as well on
all architectures because it provides a plugin for Frama-C which
contains a hash of some internal modules of Frama-C (that's needed by
OCaml).

And yes, the runtime dependencies of Why are somehow broken since it
doesn't reflect the need of at least the version of Frama-c which was
used during the build. I intended to work on that but didn't find
time. It will be fixed for Wheezy.

Regards,

-- 
Mehdi Dogguy

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message --- 
On Tue, 2010-10-05 at 19:21 +0200, Mehdi Dogguy wrote:
> On 07/09/2010 20:06, Adam D. Barratt wrote:
> > On Tue, 2010-09-07 at 11:54 +0200, Mehdi Dogguy wrote:
> >> Would it be ok for upload an updated Frama-C package with this change
> >> only?  Uploading a new Frama-C would require rebuilding Why as well on
> >> all architectures because it provides a plugin for Frama-C which
> >> contains a hash of some internal modules of Frama-C (that's needed by
> >> OCaml).
[...]
> Uploaded.

Unblocked, and binNMUs scheduled.

Regards,

Adam

--- End Message ---
Reply to: