From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefan_seefeld@mentor.com (Stefan Seefeld) Date: Tue, 11 Feb 2014 15:55:56 -0500 Subject: [lttng-dev] RFC: Fix crash in dlerror() In-Reply-To: <1494953964.23233.1392151900002.JavaMail.zimbra@efficios.com> References: <52F55511.2080309@mentor.com> <1380151240.21051.1391875592403.JavaMail.zimbra@efficios.com> <52F66118.5010003@mentor.com> <905376946.21151.1391898148330.JavaMail.zimbra@efficios.com> <52F9746F.5070302@mentor.com> <1494953964.23233.1392151900002.JavaMail.zimbra@efficios.com> Message-ID: <52FA8E5C.40203@mentor.com> On 02/11/2014 03:51 PM, Mathieu Desnoyers wrote: > ----- Original Message ----- >> From: "Stefan Seefeld" >> I'm actually not quite sure what behaviour I would prefer as a user. My >> library-author feeling tell me to not abort the process, but return an >> error condition (i.e., NULL) and let the caller take care of how to >> handle it. >> On the other hand, not finding malloc certainly is a critical error. >> And, this isn't a library in the proper sense, but a preloaded wrapper, >> so users can always re-run his apps without it. >> Hmm... > > I'm tempted to go the shortcut route (abort()) since this is really just a > wrapper. OK, fair enough. > I'm attaching an updated version, which fixes a couple of incorrect > handling of the realloc case for the static allocator. I did not add yet the > mmap() stuff, since it adds a bit of complexity to the patch, and I would be > tempted to keep things simple in -rc. I really doubt that real-life use-cases > will have error messages going beyond 4kB. And if it ever happens, we'll hit a > abort() within the wrapper, and it will be easy to fix. I'm tempted to leave > this without the mmap stuff for 2.4, so we don't add regressions late in the > cycle, is that OK with you ? Sounds good. Thanks, Stefan -- Stefan Seefeld CodeSourcery / Mentor Graphics http://www.mentor.com/embedded-software/