Date: Sun, 30 Nov 2014 21:25:31 +0000 From: bugzilla-noreply@freebsd.org To: office@FreeBSD.org Subject: [Bug 188088] editors/openoffice-4 4.0.1 crash on format cells Message-ID: <bug-188088-25061-GuQ5p9pGdY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-188088-25061@https.bugs.freebsd.org/bugzilla/> References: <bug-188088-25061@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188088 Don Lewis <truckman@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Closed |Open Resolution|FIXED |--- --- Comment #13 from Don Lewis <truckman@FreeBSD.org> --- It could be a race condition, or it could be a memory use after free bug. On HEAD, malloc() debugging is enabled, which overwrites freed memory with garbage. If the app tries to use some data structure that has been freed, then it will get garbage and might crash. On RELEASE, malloc() debugging is disabled. When the app frees some memory, malloc() might call madvise(..., MADV_FREE). In some cases the memory contents might be preserved, but in other cases the memory might get zeroed. From madvise(2): MADV_FREE Gives the VM system the freedom to free pages, and tells the system that information in the specified page range is no longer important. This is an efficient way of allowing malloc(3) to free pages anywhere in the address space, while keeping the address space valid. The next time that the page is referenced, the page might be demand zeroed, or might contain the data that was there before the MADV_FREE call. References made to that address space range will not make the VM system page the information back in from backing store until the page is modified again. What doesn't fit is that I'd expect the problem to crop up on a busy machine with a short of memory and have a better chance of working on an idle machine. I just looked more closely at stack trace in #10. Looks like a call to location 0 is triggering the SIGSEGV. Strange ... I'm reopening this PR. Unfortunately at the moment I can only test on an i386 machine running 8.4 since the hdd in my HEAD system croaked. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-188088-25061-GuQ5p9pGdY>