sprintf memory leak (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum



Message

gregmb -> sprintf memory leak (Sep. 15, '06, 5:12:22 PM)

I haven't seen this mentioned any where.

SFU 3.5, XP Pro

Does anyone know of a memory leak associated with sprintf()

I have an app. that calls sprintf() a large number of times and it has a memory leak.
When I comment out the sprintf() usage, no more memory leak.

Anybody else seen this type of behavior?

Is there a HotFix for this?

Thank
Greg



Rodney -> RE: sprintf memory leak (Sep. 15, '06, 5:27:51 PM)

There's no hotfix associated with anything like this.

The closest I've done here is to implement asprint/vasprint in libport
since these API were missing. So that would be a work-around for now.

I'll look into it more.



Rodney -> RE: sprintf memory leak (Sep. 17, '06, 11:28:45 PM)

I forgot to ask before...
Can you give a sample of one of the sprintf()'s that you think
is leaking? Just so I'm repeating what you are doing in case it
is related to one of the print types.
(I've had a test loop running for several hours with no leak).



gregmb -> RE: sprintf memory leak (Sep. 19, '06, 11:02:10 AM)

The code goes something like this.

staring point:

updateRfMon(&statblock->AcqShortRfLimit,
&CurrentStatBlock.AcqShortRfLimit,
'L', 4, "W",
RF10s1LimVal + i * 4);

Where statblock->AcqShortRfLimit & CurrentStatBlock.AcqShortRfLimit are unsigned long
RF10s1LimVal is just a defined integer #define RF10s1LimVal 10

static void
updateRfMon(unsigned long *newval,
unsigned long *oldval,
char justify,
int width,
char *unitstr,
int str_num)
{
if (*oldval != *newval) {
char buf[20];
*oldval = *newval;
power_format(buf, *newval, justify, width, unitstr);
disp_string(str_num, buf);
}
}


This is the routine that has the sprintf call, as you can see I tried ifdef out the
one sprintf() call since I thought maybe the one syntax wasn't handled by interix, but
even the simplified sprintf() still had the leak.

Just commenting out just the sprintf() lines stopped the leak.

static void
power_format(char *buf, long uwatts, char justify, int width, char *units)
{
float watts;

/* fprintf(stderr,"buf= 0x%lx, uwatts: %ld, just: '%c', width: %d, units: 0x%x\n",
buf,uwatts,justify,width,units); */

watts = uwatts * 1e-6;
if (watts < 99.9) {
switch (justify) {
case 'r': case 'R':
#ifndef __INTERIX /* this format causes interix to leak memory */
sprintf(buf,"%*.1f", width, watts);
#else
sprintf(buf,"%4.1f", watts); /* this too leaks memory */
#endif
break;
case 'l': case 'L':
sprintf(buf,"%.1f", watts);
break;
}
} else {
switch (justify) {
case 'r': case 'R':
#ifndef __INTERIX /* this format causes interix to leak memory */
sprintf(buf,"%*d", width, (int)(watts + 0.5));
#else
sprintf(buf,"%4d", (int)(watts + 0.5)); /* this too leaks memory */
#endif
break;
case 'l': case 'L':
sprintf(buf,"%d", (int)(watts + 0.5));
break;
}
}
if (units && *units) {
strcat(buf, " ");
strcat(buf, units);
}
}

It a bit convoluted for historical reasons, but has worked on Linux and Solaris for years.

Greg



markfunk -> RE: sprintf memory leak (Sep. 19, '06, 12:25:17 PM)

Why do you think there is a memory leak ?
What's your evidence ?

How are you compiling this ? (cc or gcc ?)
Any compiler options ?

What version of SFU and Interix are you using ?
(ie) what's the output from "uname -X"

Can you provide a complete sample that we can cut/paste
into a file and will cleanly compile without making any changes.
This improves the chance we'll see your problem and perhaps suggest a fix.



gregmb -> RE: sprintf memory leak (Sep. 20, '06, 4:57:00 PM)

I've been working on getting a simple example to show this problem.
But wouldn't you know in the cases I've tried so far, I can't get it to show a
memory leak.

yet the full App shows it.

I've another application that is showing a similar pattern of increasing it's
memory foot-print by 4K bytes every so often, but I have not narrowed it
down to what might be causing this one. Its a fairly complex multi-thread App.

I'll keep working to reproduce this leak in a simple case.



gregmb -> RE: sprintf memory leak (Oct. 6, '06, 7:13:28 PM)

I now have a simple case that exhibits this leak.

 

#include <stdio.h>


void updateRfMonAvg();

int main(int argc, char* argv[]) 
{
    
   char buf[20];
   double RFMonPct;
 
   RFMonPct = 0.0; 
 
    while (1) 
    {
        sprintf(buf, " %1.1f", RFMonPct);
        // fprintf(stdout,"->> buf: '%s', RFMonPct: %lf\n", buf,RFMonPct);
    }
    
}


compile the as follows:

cc -g -D_ALL_SOURCE -D_USE_LIBPORT -D_REENTRANT -DNOASYNC -DUSE_HTONS -o lktest2 lktest.c

run, there is now output, but the Windows task manager will so it consuming memory



mkoeppe -> RE: sprintf memory leak (Oct. 8, '06, 11:11:27 AM)

I could reproduce the memory leak on W2KSP4, SFU 3.5 SP-8.0.1969.45 with:

 

gcc -g -o lktest lktest.c



mgoddard -> RE: sprintf memory leak (Oct. 9, '06, 6:53:43 AM)

I have a problem with sprintf which might be related if this is a multi-threaded application. When formatting floating point values (as in your example) sprintf uses a routine called __dtoa() which doesn't appear to be thread safe. I've seen reports of errors with this routine in FreeBSD and possibly this has been inherited by Interix.

In a multi-threaded application this causes a SIGSEGV, heap corruption or the application locks-up with most threads in memory related functions. When this problem occurs the application often terminates but doesn't generate a core file.

SFU 3.5 at file level xxxx.45

Does anybody know if this code has been corrected in the LIBC provided with SUA ?



mkoeppe -> RE: sprintf memory leak (Oct. 9, '06, 1:34:52 PM)

There is a libc update, MS KB 902074 http://support.microsoft.com/default.aspx?scid=kb;en-us;902074
which I had installed already.



mgoddard -> RE: sprintf memory leak (Oct. 9, '06, 5:39:08 PM)

Thanks for the libc update information. I'm definitely suffering from this problem my process currently has 120,000 handles.

I'll get this update but it doesn't address my other problem of sprintf not being thread safe when formatting floating point values. I've had to update my code to single thread sprintf calls that format floating point values and now I don't get SIGSEGV errors or storage corruption. This problem is most severe on multi-processor machines as you'd expect with a threading race condition.



Rodney -> RE: sprintf memory leak (Oct. 10, '06, 5:32:17 AM)

The Interix stdio is based on the 4.4BSD release.
There are changes after that to the code.

The FBSD __dtoa() code, AFAIK, was based on the 4.4BSD code and then
was changed to some newer code a while back. So I don't know if the
FBSD comments you were reading relate to the older or newer FBSD code.
Either way it's likely a moot point because of other changes.

Your going to have to report the problem to MS support to get a fix for
version 3.5 and 5.2. Same for sprintf() not being thread-safe with floating
point output.



gregmb -> RE: sprintf memory leak (Oct. 13, '06, 6:47:48 PM)

I've talked to MS and sent them my small program that shows the sprintf leak.
My sample code, previous posted, is single threaded, unless SFU is doing
something I don't know about.

They gave me two HotFixes: 913030 & 921207 (which did NOT fix the problem)

I'm waiting to hear back on a solution or work around at this point.
The time frame I was given was not encouraging ( ~6 months)

Would it be possible to take, say the a linux source for sprintf or similar
and be able to use that instead of the SFU's leaky one?

Greg



Rodney -> RE: sprintf memory leak (Oct. 13, '06, 8:31:52 PM)

> The time frame I was given was not encouraging ( ~6 months)

mmm. Long time. I did post a bug report to the dev group too.
I think it's not going to get looked at until Vienna (the next codename).
The side effect of your bug report to PSS is that a hotfix can get released.
Apparently even if it's "obvious" that a bug should be back-patched with
a hotfix, a hotfix can only happen if there is an external need for it.
I'm going through this for the gcc DEP fix for 3.5 now.

> Would it be possible to take, say the a linux source for sprintf or similar
> and be able to use that instead of the SFU's leaky one?

No, don't do that.
You'll be really messed then.
The stdio is based on Chris Torak's BSD stdio. But it's been modified
with an opaque structure for threading and locking. I reverse engineered
enough of it back in 2005 for the libport work. Given we know where
the problem is, if you want a fast-ish solution, extending/adding to libport
is the way to go since the other functions are already there.



gregmb -> RE: sprintf memory leak (Oct. 14, '06, 4:00:20 PM)

A fast-ish solution is what I need. Having to waiting 6 months for MS, will pretty much result
in this project being terminated. So I'm will to try anything at this point. The best being an
sprintf() function in libport that can just override the stdio version, avoiding having to change
alot of calls.

When you say teh dev group, you mean MS development for SFU?

Thanks
Greg



Rodney -> RE: sprintf memory leak (Oct. 14, '06, 4:18:51 PM)

> When you say teh dev group, you mean MS development for SFU?

Yes. I'm not sure what its name is now since SFU is EOL. But the same group.

I have a non-leaking version running now. There's an odd call to _aulldvrm()
injected by the c89/MSVC compiler which can't link. I have a gcc version going
for now while I try to stop MSVC from doing that crap. I'll bundle it later
this weekend. I haven't done any stress testing with threads on it yet.
The fix is more than just sprintf() BTW. It's a tree'd thing that all functions
that eventually converge to the function that has the error need to be done
so the shipped version of the erro doesn't get picked up.



gregmb -> RE: sprintf memory leak (Oct. 14, '06, 8:14:26 PM)

When you say SFU is EOL, does this mean MS is no longer going to support Interix/SFU
on XP or Vista ?

Let me know when there is a new version of libport with this and I'll try it out.

Thanks
Greg



Rodney -> RE: sprintf memory leak (Oct. 14, '06, 10:23:16 PM)

SFU EOL's at 3.5 because most of the components that make up SFU
have gone into the base OS release. Support for SFU goes to 2011
(extended support until 2014) and SFU 3.5 is available for download
until 2009. This was announced over a year ago (Apr/2005). So Interix
3.5 is part of SFU 3.5. Interix 5.2 is under the SUA (Subsystem for
Unix-based Applications) in W2K3/R2. Interix 6.0 is in the Vista release.
So Interix continues.



Rodney -> RE: sprintf memory leak (Oct. 16, '06, 4:06:45 PM)

Sorry for the delay. MSVC is being a problem still.



gregmb -> RE: sprintf memory leak (Oct. 16, '06, 5:27:24 PM)

Just an interesting note on this leak, If the value is something other than 0.0,
e.g. 0.1,
then the above program doesn not leak.



Page: [1] 2   next >   >>



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.047