Bug 144142 - double free or corruption (!prev) in Gnome application
double free or corruption (!prev) in Gnome application
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-04 15:35 EST by Erich Schroeder
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-31 20:25:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Erich Schroeder 2005-01-04 15:35:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
I submitted this because it is similar to a few other open bugs
(138942 and 139712 among others). The problem comes shows up when
using gphpedit version 9.50-1 as downloaded from the gphpedit.org
site. I have submitted the following to their bug site:
*************
http://www.gphpedit.org/bugs/bug_view.php?id=132

I'm running Fedora Core 3, up to date as of Jan 3, 2005 (today). Using
the rpm-packaged version of gphpedit 0.9.50. Running under gnome.

After doing a search and replace on "whole document" with the "replace
all" button, the window indicating the number of replacements comes
up. On clicking the "ok" button, the popup window closes and gphpedit
stops responding and must be killed. The terminal from where gphpedit
was launched has the following message

*** glibc detected *** double free or corruption (!prev): 0x08d99550 ***

The hex address differs. This does not happen if I only do a single
"find and replace" but is consistant with the "Replace All".

*************
As in another bug (139712) setting MALLOC_CHECK_ environmental
variable to 0 works around the problem. The problem does not exist in FC2.

# rpm -q xorg-x11
xorg-x11-6.8.1-12.FC3.21



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. install gphpedit (rpm, source rpm, or config-make-install)
2. open any file in gphpedit
3. choose search and replace, enter items for search/replace, and
click the "replace all" button. 
4. Popup window show up, on clicking "OK", window closes and
application  freezes with the  "double free or corruption" message in
terminal.
    

Actual Results:  Application freezes after closing popup window

Expected Results:  Popup window should close and the application
should continue (as it does when $MALLOC_CHECK_=0)



Additional info:

I have submitted this to the gPHPEdit authors, but it seemed to be
similar to other open problems in the fedora bugzilla.
Comment 1 Sitsofe Wheeler 2005-01-04 17:55:17 EST
This sounds like an application problem and is actually unrelated to xorg. 

Basically glibc is warning you about a dangerous bug *in gphpedit*. The reason
the message appears is because gphpedit is faulty and turning off the warning by
doing MALLOC_CHECK_=0 is only allowing silent memory corruption to happen. This
could be disasterous (imagine an unseen line of the PHP you are editing having a
"<" change to ">").

Reporting the bug to the gphpedit authors is pretty much the best thing you
could have done short of pulling out gdb/valgrind and fixing the source of
gphpedit yourself.

Since gphpedit is not a part of Fedora there is nothing more the devs can do on
this end. I suspect all the other double free warning bugs are against packages
actually shipped with base Fedora...
Comment 2 Erich Schroeder 2005-01-10 13:03:36 EST
I imagine this is correct, although I posted it here because I see the
problem in FC3 but not FC2. Anyway, sorry if it is wasting time.

eks
Comment 3 Mike A. Harris 2005-01-31 20:25:12 EST
Sitsofe is correct, this is not an xorg-x11 bug, nor a Fedora Core
bug.  It is a bug in the application you are using.  The reason
the problem shows up in Fedora Core 3, is because FC3 glibc has
new security features designed to detect security flaws in
applications and report warnings when an application has a
security vulnerability.

This feature was not present in Fedora Core 2, so running this
insecure application in FC2 will not give you any security warnings,
however in both cases the software is insecure.

The problem should be reported directly to the authors of the
insecure application, so they can fix it.

Setting status to NOTABUG, because this is not an xorg-x11 or
Fedora Core bug.

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