Re: Mtest_4_sql
Romulo, Jennie,
after a test has finished and the Mserver has stopped, Mtest does a "sanity
check" to see, whether the used ports/sockets (MAPI and/or XRPC) are free,
again, i.e., have been released properly.
If not, the OS will "eventually" release the abandoned ports/sockets, but
that may take up to a couple of minutes, which is obviously not handy if
Mtest "immediately" wants/needs to run the next test, which then fails if
the port/socket is still blocked.
Hence, Mtest does two checks:
(1) before running a test that requires MAPIPORT (all .milC, .sql and .xq
tests) and/or XRPCPORT (*all* .xq tests, since module pathfinder starts the
XRPC server / admin console by default), Mtest check whether the respetive
port number(s) is/are available, and otherwise randomly picks a new one.
(2) after such a test has finished, Mtest checks whether the used port
number(s) is/are available, again, i.e., have been release properly
before/when quitting Mserver.
The second test is mainly for debugging --- not releasing them properly is
not a severe bug, but "merely" a nasty "leak" and "inconvenience". That's
why Mtest only emits the message you see to the console, but does not add
this to the tests' output.
After all the port changes (i.e., replacement of MAPIPORT, SQLPORT,
XQUERYPORT by a single MAPIPORT and introduction of XRPCPORT (and its
predicessors with varying names) in particular the second test did no longer
work properly (or not at all), until I fixed Mtest last week.
Being neither the MAPI nor the XRPC guy, I have no idea, why/where the ports
are not released properly.
(Continue reading)
The compiler doesn not know the realloc() and the malloc() function() in the current setting. When I change them into PFrealloc() and PFmalloc() it compiles. But then I still have problems with the "free(buf);" line. There is no PFfree(); and I think GDKfree() will not always work, JanF. On Tuesday 01 May 2007 17:58, Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/mil > In directory sc8-pr-cvs16:/tmp/cvs-serv17830 > > Modified Files: > milprint_summer.c > Log Message: > When you want to use a library function, make sure the appropriate > include file is included. For alloca there is an extra twist: for the > way to include alloca.h see e.g. monet_utils.mx. Do not hide the lack > of a declaration with a cast. The compiler then thinks the function > returns an int which may well be smaller in space than the actual > value, and hence some bytes of the value may get lost. > > Having said this, alloca should *not* be used in a loop. It allocates > memory in each iteration which is only freed at the end of the > function. If the loop loops many times, that can be a lot of memory > which is allocated on the stack (which is a very finite resource!). > > Here ends today's lesson. > >
Well, actually, I'm afraid you just re-introduced the problem:
in short
========
size_t maxbufsize = 0;
char *nme = NULL;
while (...)
{
...
if (maxbufsize < strlen(tpe) + 4) {
maxbufsize = strlen(tpe) + 4;
nme = nme ? realloc(nme, maxbufsize) : malloc(maxbufsize);
}
...
if (...) {
*nme++ = 'x';
...
}
}
if (nme)
free(nme);
...
========
IMHO does not work, since the nme++ changes nme, causing later realloc(nme,
maxbufsize) and/or free(nme) to "behave strangly" --- or simply segfault ...
RSS Feed