Bug 144142

Summary:	double free or corruption (!prev) in Gnome application
Product:	[Fedora] Fedora	Reporter:	Erich Schroeder <erich>
Component:	xorg-x11	Assignee:	X/OpenGL Maintenance List <xgl-maint>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-02-01 01:25:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Erich Schroeder 2005-01-04 20:35:44 UTC

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 22:55:17 UTC

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 18:03:36 UTC

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-02-01 01:25:12 UTC

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.