RULE regression test failure

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

With the recent talk of RULE regression failures, I thought I'd bring back
up that I _always_ have a rule failure on Freebsd/alpha.

Hm, what do you get from
explain SELECT * FROM shoe_ready WHERE total_avail >= 2;
in the regression database?

regards, tom lane

Ummmm...how do I make the regression database!? Do I have to do
installcheck instead of check?

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Ummmm...how do I make the regression database!? Do I have to do
installcheck instead of check?

That's the easiest way; or you can restart the temp postmaster that
the regression script starts and kills.

regards, tom lane

On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote:

Ummmm...how do I make the regression database!? Do I have to do
installcheck instead of check?

yes

Database is 'regression'

g

An aside.

In the fulltextindex code I'm trying to figure out what's breaking the
attached code segment.

Basically the data->vl_len line causes a segfault on the second time thru
the while loop. I can't figure it out. I can't write to the value, but
why? Basically with a word like 'john', it is inserting 'hn', then 'ohn'
and then 'john' into the database.

Thanks for any help for me getting this in for the beta!

Chris
-------------------------------------

struct varlena *data;
char *word = NULL;
char *cur_pos = NULL;
int cur_pos_length = 0;

data = (struct varlena *) palloc(column_length);

while(cur_pos > word)
{
cur_pos_length = strlen(cur_pos);
/* Line below causes seg fault on SECOND iteration */
data->vl_len = cur_pos_length + sizeof(int32);
memcpy(VARDATA(data), cur_pos, cur_pos_length);
values[0] = PointerGetDatum(data);
values[1] = 0;
values[2] = oid;

ret = SPI_execp(*(plan->splan), values, NULL, 0);
if(ret != SPI_OK_INSERT)
elog(ERROR, "Full Text Indexing: error executing plan in insert\n");

cur_pos--;
}

Attached.

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

struct varlena *data;
char *word = NULL;
char *cur_pos = NULL;
int cur_pos_length = 0;

data = (struct varlena *) palloc(column_length);

while(cur_pos > word)
{
cur_pos_length = strlen(cur_pos);
/* Line below causes seg fault on SECOND iteration */

You are not telling the whole truth here, as the above code excerpt
will obviously never iterate the WHILE even once. "NULL > NULL" is
false in every C I ever heard of.

Also, how much is column_length and how does it relate to the amount
of data being copied into *data ?

regards, tom lane

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Hm, what do you get from
explain SELECT * FROM shoe_ready WHERE total_avail >= 2;
in the regression database?

[this plan]

That seems substantially the same plan as I see here. I guess
that the different output order must reflect a platform-specific
difference in qsort()'s treatment of equal keys.

Probably the best answer is to add "ORDER BY shoename" to the test
query to eliminate the platform dependency. Any objections out there?

regards, tom lane

That seems substantially the same plan as I see here. I guess
that the different output order must reflect a platform-specific
difference in qsort()'s treatment of equal keys.

Probably the best answer is to add "ORDER BY shoename" to the test
query to eliminate the platform dependency. Any objections out there?

None here.

Chris

OK, I was probably a little aggressive in my pruning...BTW, this code was
not written by me...

--------------------------------

struct varlena *data;
char *word = "john";
char *cur_pos = NULL;
int cur_pos_length = 0;

data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
word_length = strlen(word);
cur_pos = &word[word_length - 2];

while(cur_pos > word)
{
cur_pos_length = strlen(cur_pos);
/* Line below causes seg fault on SECOND iteration */
data->vl_len = cur_pos_length + sizeof(int32);
memcpy(VARDATA(data), cur_pos, cur_pos_length);
values[0] = PointerGetDatum(data);
values[1] = 0;
values[2] = oid;

ret = SPI_execp(*(plan->splan), values, NULL, 0);
if(ret != SPI_OK_INSERT)
elog(ERROR, "Full Text Indexing: error executing plan in insert\n");

cur_pos--;
}

On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote:

--------------------------------

struct varlena *data;
char *word = "john";
char *cur_pos = NULL;
int cur_pos_length = 0;

data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
word_length = strlen(word);
cur_pos = &word[word_length - 2];

while(cur_pos > word)
{
cur_pos_length = strlen(cur_pos);
/* Line below causes seg fault on SECOND iteration */
data->vl_len = cur_pos_length + sizeof(int32);
memcpy(VARDATA(data), cur_pos, cur_pos_length);
values[0] = PointerGetDatum(data);
values[1] = 0;
values[2] = oid;

ret = SPI_execp(*(plan->splan), values, NULL, 0);
if(ret != SPI_OK_INSERT)
elog(ERROR, "Full Text Indexing: error executing plan in insert\n");

cur_pos--;
}

That would imply the SPI_execp call is trashing the value of data. Have you
confirmed that? (Sometimes it helps to confirm exactly where a pointer is
getting hammered.)

column_length is something sensible like word_length I presume.

That sizeof(int32) should really be VARHDRSZ imo, but I can't see how that's
breaking it.

Disclaimer: I have no idea what I'm doing here.

--
Nigel J. Andrews

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

struct varlena *data;
char *word = "john";
char *cur_pos = NULL;
int cur_pos_length = 0;

data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
word_length = strlen(word);
cur_pos = &word[word_length - 2];

while(cur_pos > word)
{
cur_pos_length = strlen(cur_pos);
/* Line below causes seg fault on SECOND iteration */
data->vl_len = cur_pos_length + sizeof(int32);
memcpy(VARDATA(data), cur_pos, cur_pos_length);
values[0] = PointerGetDatum(data);
values[1] = 0;
values[2] = oid;

ret = SPI_execp(*(plan->splan), values, NULL, 0);
if(ret != SPI_OK_INSERT)
elog(ERROR, "Full Text Indexing: error executing plan in insert\n");

cur_pos--;
}

Are you sure it's actually segfaulting *at* the store into data->vl_len?
This seems hard to believe, if data is a local variable. It seems
possible that the storage data is pointing to gets freed during
SPI_execp, but that would just mean you'd be scribbling on memory that
doesn't belong to you --- which might cause a crash later, but surely
not at that line.

It would be worth looking to see which context is active when you do the
palloc() for data, and then watch to see if anything does a
MemoryContextReset on it. (If you are running with asserts enabled,
an even simpler test is to look and see if data->vl_len gets changed
underneath you.)

Also, I'm still wondering if column_length is guaranteed to be longer
than word_length.

regards, tom lane

OK, patch attached that adds ORDER BY to the problem regression query.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

That seems substantially the same plan as I see here. I guess
that the different output order must reflect a platform-specific
difference in qsort()'s treatment of equal keys.

Probably the best answer is to add "ORDER BY shoename" to the test
query to eliminate the platform dependency. Any objections out there?

None here.

Chris

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

All regression tests now pass perfectly for me. Thanks.

Chris