Bug 515731

Summary: Distinguish between realloc functions in realloc size 0 error messages
Product: [Developer tools] valgrind Reporter: Paul Floyd <pjfloyd>
Component: memcheckAssignee: Paul Floyd <pjfloyd>
Status: REPORTED ---    
Severity: normal CC: mark
Priority: NOR    
Version First Reported In: 3.27 GIT   
Target Milestone: ---   
Platform: Other   
OS: All   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: initial patch, FreeBSD only
Patch with Linux expecteds
Revised patch

Description Paul Floyd 2026-02-08 17:34:53 UTC
There are 4 realloc functions that we support (realloc, reallocf, reallocarray and malloc_zone_realloc). However their error messages all use just "realloc()"
Comment 1 Paul Floyd 2026-02-08 17:52:50 UTC
Created attachment 189359 [details]
initial patch, FreeBSD only

Need to run on Linux to update the expecteds there
Comment 2 Paul Floyd 2026-02-08 18:44:02 UTC
Created attachment 189360 [details]
Patch with Linux expecteds

Also fixed a warning
Comment 3 Mark Wielaard 2026-02-09 15:12:04 UTC
(In reply to Paul Floyd from comment #2)
> Created attachment 189360 [details]
> Patch with Linux expecteds
> 
> Also fixed a warning

I think this should be fine since no error kinds are really changed, just the message printed. So suppressions should still work as is?

You might want to also put static const HChar* reallocKinds[] into pub_tool_tooliface.h in case other tools might want to print the actual function name.
Comment 4 Paul Floyd 2026-02-09 15:39:35 UTC
(In reply to Mark Wielaard from comment #3)
> (In reply to Paul Floyd from comment #2)
> > Created attachment 189360 [details]
> > Patch with Linux expecteds
> > 
> > Also fixed a warning
> 
> I think this should be fine since no error kinds are really changed, just
> the message printed. So suppressions should still work as is?

Ues, the suppressions use "ReallocSizeZero" which I'm not going to change.

> You might want to also put static const HChar* reallocKinds[] into
> pub_tool_tooliface.h in case other tools might want to print the actual
> function name.

Hmm. Thinking of other tools maybe I can use

            hasfn = VG_(get_fnname)(ai->Addr.Stack.epoch,
                                    ai->Addr.Stack.IP, &fn);

then I could leave the error struct alone, it already has

      struct {
         AddrInfo ai;
      } ReallocSizeZero;
Comment 5 Paul Floyd 2026-02-10 20:00:58 UTC
Created attachment 189446 [details]
Revised patch

I've changed approach and added a new function that gets the first function name from an ExeContext. This is much less pervasive a change.

It could also be be extended to the fishy and aligned memcheck errors which use generalised names that don't distinguish between nothrow(true) and nothrow(false) operator new overloads. That might not be entirely a bad thing.