Here’s a sample .c program that crashes malloc… any suggestions?
begin 666 malloc.c
M+RH@;6%L;&]C+F,@(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" J+PHOB @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(“HO"B\J(%1H
M:7,@<’)O9W)A;2!C<F%S:&5S(&EN(’%N>#0N,C4@(” @(" @(" @(" @(" @
M(" @(" @(" @(" @B*+RH@5&AI<R!P<F]G<F%M(&1O97,@;F]T(&-R87-H
M(‘5N9&5R(’%N>#0N,C,@(" @(" @(" @(" @(" @(" J+PHOB @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(“HO"B\J($D@=V%S('1R>6EN9R!T;R!R97!R;V1U8V4@82!M96UO
M<GD@;&]S<R!B=6<@(” @(" @(" @(" @(" @B*+RH@(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" J+PH"B\J(%1O(&-O;7!I;&4L(‘EO=2!M=7-T(&QI;FL@=VET:"!L:6)M
M86QL;V,S<BYA+B!&;W(@97AA;7!L93H@B*+RH@(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" J
M+PHOB @8V,@+7<S(“UO;6%L;&]C(“UL;&EB;6%L;&]C,W(N82!M86QL;V,N
M8R @(” @(” @(" @(" @(" @(“HO"B\J(” @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @B*"@H
M=F]I9"!T:’)E860H=F]I9" J('8I"GL=F]I9" J<‘1R.PH)9F]R*#L[0H)
M>PH)"7!T<B ](&UA;&QO8R@Q,# P,# I.PH)"69R964H<'1R3L*“7T*?0H*
M;6%I;B@@:6YT(&%R9V,L(&-H87(@F%R9W9;72 I"GL=F]I9” J<‘1R.PH)
M7V)E9VEN=&AR96%D*‘1H<F5A9"P@(" @(" @(" @(" O+R!T:’)E860@9G5N
M8W1I;VX*“0D)“0DP+” @(” @(" @(" @(" @+R@<W1A8VL@8F]T=&]M"@D)
M"0D).#$Y,BP@( D)"2\O(’-T86-K(’-I>F4*"0D)"0DP3L@(" @(" @(" @
M(" @+R@87)G=6UE;G0@;&ES= H)9F]R("@[.RD"7L*“0EP=’(@/2!M86QL
J;V,H,3 P,# P3L"0ED96QA>2@Q3L"0EF<F5E*’!T<BD[”@E]"GT*
`
end
Mike Royer <support@tilcon.com> wrote:
Here’s a sample .c program that crashes malloc… any suggestions?
From the comments:
/* To compile, you must link with libmalloc3r.a. For example: /
/ /
/ cc -w3 -omalloc -llibmalloc3r.a malloc.c /
/ */
Don’t compile -llibmalloc3r.a. That gives a non-standard malloc
library. I would bet that this malloc library is not thread
safe.
I’ve got it running linked against the regular malloc library,
and its been running for a while, now, without crashing.
How long should I expect to wait? (Mine’s been running 15 minutes
or so, at this point.)
-David
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void thread(void * v)
{
void *ptr;
for(;
{
ptr = malloc(100000);
free(ptr);
}
}
main( int argc, char *argv[] )
{
void *ptr;
_beginthread(thread, // thread function
0, // stack bottom
8192, // stack size
0); // argument list
for (;
{
ptr = malloc(100000);
delay(1);
free(ptr);
}
}
\
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Mike Royer <> support@tilcon.com> > wrote:
Here’s a sample .c program that crashes malloc… any suggestions?From the comments:
/* To compile, you must link with libmalloc3r.a. For example: /
/ /
/ cc -w3 -omalloc -llibmalloc3r.a malloc.c /
/ */Don’t compile -llibmalloc3r.a. That gives a non-standard malloc
library. I would bet that this malloc library is not thread
safe.
IMHO … it is better to build your own lib based
on the GNU malloc module.
I know installations where it’s working rock
solid.
Well … try to avoid that so called ‘thread
support’ of QNX4.
Armin
I’ve got it running linked against the regular malloc library,
and its been running for a while, now, without crashing.
How long should I expect to wait? (Mine’s been running 15 minutes
or so, at this point.)-David
#include <stdio.h
#include <stdlib.h
#include <unistd.hvoid thread(void * v)
{
void *ptr;
for(;
{
ptr = malloc(100000);
free(ptr);
}
}main( int argc, char *argv[] )
{
void *ptr;
_beginthread(thread, // thread function
0, // stack bottom
8192, // stack size
0); // argument list
for (;
{
ptr = malloc(100000);
delay(1);
free(ptr);
}
}–
QNX Training Services
dagibbs@qnx.com
You should have been able to see the problem by then. OK, remind me… why
does libmalloc3r.a exist? Does it handle something that the standard malloc
doesn’t?
Michel Royer <support@tilcon.com> wrote:
You should have been able to see the problem by then. OK, remind me… why
does libmalloc3r.a exist? Does it handle something that the standard malloc
doesn’t?
I don’t actually know – it probably does some things in a different
way from the standard malloc – but I didn’t have anything to do with
the package that it is in, sorry.
-David
QNX Training Services
dagibbs@qnx.com
It will return memory to the os when it’s freed (it’s using sharemem).
It also allows program that share segments (such as netraw app) to
use malloc
It’s think it also help port so Unix app use free(NULL)
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:93i5f4$3p5$1@nntp.qnx.com…
Michel Royer <> support@tilcon.com> > wrote:
You should have been able to see the problem by then. OK, remind me…
why
does libmalloc3r.a exist? Does it handle something that the standard
malloc
doesn’t?I don’t actually know – it probably does some things in a different
way from the standard malloc – but I didn’t have anything to do with
the package that it is in, sorry.-David
QNX Training Services
dagibbs@qnx.com
Thanks guys.
BTW - I’m told that my sample worked fine with libmalloc3r.a in QNX V4.23,
but crashed in V4.25… does that help shed any light?
Mario Charest wrote in message <93i6qe$4db$1@nntp.qnx.com>…
It will return memory to the os when it’s freed (it’s using sharemem).
It also allows program that share segments (such as netraw app) to
use malloc
Hi you all…
I am gonna tell what happenned here in the past…
People here used to do graphical programs using graphics functions
MicrosoftC compatible supported
(but not documented) by QNX …
_registerfonts(), _setfont(), _setvideomode(), _setactivepage(),
_setcolor(), _moveto(), _lineto(),
_rectangle() and so on…
One day we updated from QNX4.24 to QNX4.25 and we had serious problems with
malloc()…
If you malloc-ed some bytes after using _setvideomode() (which implies
opening graphics mode on the console)
there was no problem but if you tried to malloc 10 KBs or so, malloc
returned with error and reported
not enough memory…
On certain Proc32 4.2x version (don’t remember exactly which one, but after
4.24H), it was reported that a memory leak had been fixed and since then our
graphics mode applications dealing “directly” with VGA did not work anymore.
QNX said that they would not fix that and that you might port your
application to Photon, for
example…
…or else you can install QNX 4.25C (for example) and Proc32 4.24H (for
example) and keep in mind that such
Proc32 version has a memory leak (which, personally, did not affect my apps
or at least i did not realize 
)
That is what we did and those graphics non-Photon applications are still
working…
What I really mean is that if what is happenning to you really affects you,
know that you can use a previous
working Proc32 version and that some times the fixing of some bugs leads to
some other new bugs…
At least it has happenned to me some zillion times
Anyway, I would have loved that QSSL had fixed that graphics mode malloc()
problem…
Greetings…
Ignacio “Nacho” Marín
“Michel Royer” <support@tilcon.com> escribió en el mensaje
news:93o227$qck$1@inn.qnx.com…
Thanks guys.
BTW - I’m told that my sample worked fine with libmalloc3r.a in QNX V4.23,
but crashed in V4.25… does that help shed any light?