bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#12242: Emacs 24.2 RC1 build fails on OpenBSD


From: Eli Zaretskii
Subject: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD
Date: Thu, 23 Aug 2012 19:06:23 +0300

> Date: Thu, 23 Aug 2012 08:12:37 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
>       Stefan Monnier <monnier@iro.umontreal.ca>,
>       Chong Yidong <cyd@gnu.org>,
>       Kenichi Handa <handa@m17n.org>,
>       jca@wxcvbn.org,
>       12242@debbugs.gnu.org
> 
> >>>>> On Wed, 22 Aug 2012 19:58:12 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
> >>> My reading of the code is that inhibiting relocation just means
> >>> that ralloc.c always asks for more memory when it cannot find a
> >>> large enough block in the existing heaps.
> >> 
> >> For example, `virtual_break_value' is not updated in that case.  It
> >> can lead to an inconsistent state as reported if r_alloc_sbrk is
> >> called with a positive argument via malloc when
> >> use_relocatable_buffers <= 0, and then it is called with a negative
> >> argument via free when use_relocatable_buffers > 0.
> 
> > I see your point.
> 
> Sorry, I noticed that the senario I gave above was actually bogus.
> Typically free will call r_alloc_sbrk(0) and check the return value
> with respect to the area to be reclaimed before calling r_alloc_sbrk
> with a negative argument.
> 
> Now I don't have a concrete senario to conclude that it is wrong to
> change use_relocatable_buffers temporarily.  I'm really sorry if my
> previous posts confused you.

No sweat.  I guess I will need to take a deeper look at the problem.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]