Free Downloads, Community Forum,
FAQs and Developer Resources


Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

All Forums Register Login Search Subscriptions My Profile Inbox
Tool Warehouse FAQs Resources Help Member List Address Book Logout

sprintf memory leak

 
Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> sprintf memory leak Page: [1]
Login
Message << Older Topic   Newer Topic >>
sprintf memory leak - Sep. 15, '06, 5:12:22 PM   
gregmb

 

Posts: 26
Status: offline
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
Post #: 1
RE: sprintf memory leak - Sep. 15, '06, 5:27:51 PM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
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.

(in reply to gregmb)
Post #: 2
RE: sprintf memory leak - Sep. 17, '06, 11:28:45 PM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
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).

< Message edited by Rodney -- Sep. 17, '06, 11:49:18 PM >

(in reply to Rodney)
Post #: 3
RE: sprintf memory leak - Sep. 19, '06, 11:02:10 AM   
gregmb

 

Posts: 26
Status: offline
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

(in reply to Rodney)
Post #: 4
RE: sprintf memory leak - Sep. 19, '06, 12:25:17 PM   
markfunk

 

Posts: 669
Joined: Mar. 31, '03,
Status: offline
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.

(in reply to gregmb)
Post #: 5
RE: sprintf memory leak - Sep. 20, '06, 4:57:00 PM   
gregmb

 

Posts: 26
Status: offline
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.

(in reply to markfunk)
Post #: 6
RE: sprintf memory leak - Oct. 6, '06, 7:13:28 PM   
gregmb

 

Posts: 26
Status: offline
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

(in reply to gregmb)
Post #: 7
RE: sprintf memory leak - Oct. 8, '06, 11:11:27 AM   
mkoeppe

 

Posts: 43
Joined: Dec. 8, '05,
Status: offline
I could reproduce the memory leak on W2KSP4, SFU 3.5 SP-8.0.1969.45 with:

gcc -g -o lktest lktest.c

(in reply to gregmb)
Post #: 8
RE: sprintf memory leak - Oct. 9, '06, 6:53:43 AM   
mgoddard

 

Posts: 3
Joined: Jun. 18, '05,
Status: offline
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 ?

(in reply to mkoeppe)
Post #: 9
RE: sprintf memory leak - Oct. 9, '06, 1:34:52 PM   
mkoeppe

 

Posts: 43
Joined: Dec. 8, '05,
Status: offline
There is a libc update, MS KB 902074 http://support.microsoft.com/default.aspx?scid=kb;en-us;902074
which I had installed already.

(in reply to mgoddard)
Post #: 10
RE: sprintf memory leak - Oct. 9, '06, 5:39:08 PM   
mgoddard

 

Posts: 3
Joined: Jun. 18, '05,
Status: offline
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.

(in reply to mkoeppe)
Post #: 11
RE: sprintf memory leak - Oct. 10, '06, 5:32:17 AM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
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.

(in reply to mgoddard)
Post #: 12
RE: sprintf memory leak - Oct. 13, '06, 6:47:48 PM   
gregmb

 

Posts: 26
Status: offline
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

(in reply to Rodney)
Post #: 13
RE: sprintf memory leak - Oct. 13, '06, 8:31:52 PM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
> 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.

(in reply to gregmb)
Post #: 14
RE: sprintf memory leak - Oct. 14, '06, 4:00:20 PM   
gregmb

 

Posts: 26
Status: offline
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

(in reply to Rodney)
Post #: 15
RE: sprintf memory leak - Oct. 14, '06, 4:18:51 PM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
> 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.

< Message edited by Rodney -- Oct. 14, '06, 4:23:02 PM >

(in reply to gregmb)
Post #: 16
RE: sprintf memory leak - Oct. 14, '06, 8:14:26 PM   
gregmb

 

Posts: 26
Status: offline
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

(in reply to Rodney)
Post #: 17
RE: sprintf memory leak - Oct. 14, '06, 10:23:16 PM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
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.

(in reply to gregmb)
Post #: 18
Page:   [1]
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> sprintf memory leak Page: [1]
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Search All Forums -

Advanced search


SPONSORS



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.063