Jan Flokstra | 2 May 09:52 2007
Picon
Picon
Picon

Re: [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.367, 1.368

I have great compilation troubles with the last lesson from the master:-) 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.
>
>
(Continue reading)

Fabian Groffen | 2 May 10:09 2007
Picon
Picon

Re: [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.367, 1.368

Hi Jan,

I experience the same issue.  The attached patch works for me.  I'm not
sure why it worked for Sjoerd here, so I'm not committing.

On 02-05-2007 09:52:24 +0200, Jan Flokstra wrote:
> I have great compilation troubles with the last lesson from the master:-) 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
(Continue reading)

Sjoerd Mullender | 2 May 10:13 2007
Picon

Re: [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.367, 1.368

Fixed.

Jan Flokstra wrote:
> I have great compilation troubles with the last lesson from the master:-) 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!).
>>
(Continue reading)

Sjoerd Mullender | 2 May 10:14 2007
Picon

Re: [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.367, 1.368

Fabian Groffen wrote:
> Hi Jan,
> 
> I experience the same issue.  The attached patch works for me.  I'm not
> sure why it worked for Sjoerd here, so I'm not committing.

Because I tried it on Windows using the Intel compiler.

> On 02-05-2007 09:52:24 +0200, Jan Flokstra wrote:
>> I have great compilation troubles with the last lesson from the master:-) 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.
(Continue reading)

Jan Rittinger | 2 May 14:31 2007
Picon

Re: [Monetdb-sql-checkins] sql/src/tools embeddedclient.mx, 1.23, 1.24 monetdb.py.i, 1.5, 1.6 prog.c, 1.17, 1.18

This problem has gone -- thanks.
The next one is already reported :)

On 04/29/2007 12:19 PM, Stefan Manegold wrote with possible deletions:
> Jan,
> 
> a similar problem actually occurred with nightly testing on Solaris/x86; cf.
> http://sourceforge.net/tracker/index.php?func=detail&aid=1709182&group_id=56967&atid=482468
> 
> Yesterday, Niels fixed it in CVS.
> 
> Could you please update and check whether the problems still occurs with
> you?
> 
> Thanks!
> 
> Stefan
> 
> On Fri, Apr 27, 2007 at 05:19:36PM +0200, Jan Rittinger wrote:
>> perhaps its triggered by Niels newest ``any type'' changes in 
>> bat_store.mx -- just guessing.
>>
> 

--

-- 
Jan Rittinger
Database Systems
Technische Universit√§t M√ľnchen (Germany)
http://www-db.in.tum.de/~rittinge/

(Continue reading)

Stefan Manegold | 2 May 23:49 2007
Picon
Picon

Re: [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.371, 1.372

Sjoerd,

didn't like my fix? ;-)

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 ...
(Continue reading)

Stefan Manegold | 2 May 23:52 2007
Picon
Picon

Re: pathfinder/compiler/mil milprint_summer.c, 1.371, 1.372

ABORT & ROLLBACK

... like CVS, mailing does not provide full ACID semantics ...

Stefan

On Wed, May 02, 2007 at 11:49:28PM +0200, Stefan Manegold wrote:
> Sjoerd,
> 
> didn't like my fix? ;-)
> 
> 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';
> 		...
> 	}
> }
(Continue reading)

Romulo Goncalves | 4 May 12:09 2007
Picon
Picon

Mtest_4_sql

I am running Mtest_4_SQL and I am getting strange error messages from 
MAPIPORT:

! Socket-Check failed for MAPIserver on <localhost:37631> with #98; 
'Address already in use' !
! MAPIPORT was not properly released by Mserver !

* (zones.test.err.FILTERED) significantly
...
* (rank.test.out.FILTERED) significantly
.
! Socket-Check failed for MAPIserver on <localhost:30932> with #98; 
'Address already in use' !
! MAPIPORT was not properly released by Mserver !

* (function_syntax.test.out.FILTERED) significantly

* (function_syntax.test.err.FILTERED) significantly
.
! Socket-Check failed for MAPIserver on <localhost:37107> with #98; 
'Address already in use' !
! MAPIPORT was not properly released by Mserver !

Any idea?

Regards,
Romulo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
(Continue reading)

Ying Zhang | 4 May 14:11 2007
Picon
Picon

Re: Mtest_4_sql

I have the same problem when testing XRPC:

======
14:09:04> tests/XRpc/insertNode.xq  (<=60,60,180) ...   1.107s
! Socket-Check failed for XRPCserver on <localhost:43811> with #98;
'Address already in use' !
! XRPCPORT was not properly released by Mserver !

insertNode.stable.out.FILTERED and insertNode.test.out.FILTERED are equal.
insertNode.stable.err.FILTERED and insertNode.test.err.FILTERED are equal.
======

Maybe related to recent changes in the (config) scripts?

Jennie

On Fri, May 04, 2007 at 12:09:38PM +0200, Romulo Goncalves wrote:
> I am running Mtest_4_SQL and I am getting strange error messages from 
> MAPIPORT:
> 
> ! Socket-Check failed for MAPIserver on <localhost:37631> with #98; 
> 'Address already in use' !
> ! MAPIPORT was not properly released by Mserver !
> 
> * (zones.test.err.FILTERED) significantly
> ...
> * (rank.test.out.FILTERED) significantly
> .
> ! Socket-Check failed for MAPIserver on <localhost:30932> with #98; 
> 'Address already in use' !
(Continue reading)

Stefan Manegold | 4 May 23:14 2007
Picon
Picon

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)


Gmane