[Bug 44600] New: Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

Bug ID: 44600
           Summary: Memory leak in toos/wmc/po.c
           Product: Wine
           Version: unspecified
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tools
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 60588
  --> https://bugs.winehq.org/attachment.cgi?id=60588
The bug trace of this ml bug.

We find a memory leak defect in the file  toos/wmc/po.c. 
I've uploaded a screenshot of the leak trace.

Gang
Sourcebrella

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #1 from Nikolay Sivov  ---
Those are build tools that only run for relatively short period of time, and
everything is released on termination anyway.

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #2 from Fan gang  ---
(In reply to Nikolay Sivov from comment #1)
> Those are build tools that only run for relatively short period of time, and
> everything is released on termination anyway.

Thanks for the reply. I've noticed that those bugs are in the tools folder,
that was why I've assigned a "normal" importance. Potential bugs are like
silent bombs in the code and they are going to bomb someone in the future, I
think you would agree with my opinion since you are much senior than me in
MySQL development. It will be great if someone fixes them when they are not
busy. :P

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #3 from Nikolay Sivov  ---
They are valid in theory, but not important in practice, and don't affect end
users. See
https://www.winehq.org/pipermail/wine-devel/2018-February/123267.html.

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #4 from Fan gang  ---
(In reply to Nikolay Sivov from comment #3)
> They are valid in theory, but not important in practice, and don't affect
> end users. See
> https://www.winehq.org/pipermail/wine-devel/2018-February/123267.html.

I agree that they are not important. But if the question has binary options
(fix or not fix). I will still stick to they should be fixed, even in a less
prioritized way.

Somebody has asked a similar question on StackOverflow. All the top voted
answers suggest closing the resource anyway.

I copied one here.

"It depends on the operating system. The majority of modern (and all major)
operating systems will free memory not freed by the program when it ends.

Relying on this is bad practice and it is better to free it explicitly. The
issue isn't just that your code looks bad. You may decide you want to integrate
your small program into a larger, long running one. Then a while later you have
to spend hours tracking down memory leaks.
Relying on a feature of an operating system also makes the code less portable."

The link:

https://stackoverflow.com/questions/2213627/when-you-exit-a-c-application-is...

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #5 from Alexandre Julliard  ---
I'd argue that the bugs are not valid even in theory. exit() frees the entire
address space, and it's a legitimate way of freeing memory. There are no leaks
to fix, and there's no reason to add explicit free() calls. They only make the
code more complex and slower, for no benefit except some misguided sense of
"following the rules".

As such, it's not a task that anybody should be working on, even at the lowest
priority. Patches that attempt to "fix" such issues will not be accepted.

[Bug 44600] Memory leak in toos/wmc/po.c

https://bugs.winehq.org/show_bug.cgi?id=44600

--- Comment #6 from Fan gang  ---
(In reply to Alexandre Julliard from comment #5)
> I'd argue that the bugs are not valid even in theory. exit() frees the
> entire address space, and it's a legitimate way of freeing memory. There are
> no leaks to fix, and there's no reason to add explicit free() calls. They
> only make the code more complex and slower, for no benefit except some
> misguided sense of "following the rules".
>
> As such, it's not a task that anybody should be working on, even at the
> lowest priority. Patches that attempt to "fix" such issues will not be
> accepted.

Sure, I will respect your decision.