Bugs item #2671445, was opened at 2009-03-07 13:45
Message generated for change (Comment added) made by skinkie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2671445&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Mapi
Group: Clients CVS Head
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stefan de Konink (skinkie)
Assigned to: Sjoerd Mullender (sjoerd)
Summary: Mapi read error when rows exceed maximum
Initial Comment:
Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f2003f8b700 (LWP 3884)]
> 0x00007f1ffe318ea4 in mapi_seek_row (hdl=0x330c140, rownr=1, whence=0)
> at ../../../src/mapilib/Mapi.mx:4178
> 4178 if (rownr > result->row_count && hdl->mid->active &&
> read_into_
> ache(hdl->mid->active, 0) != MOK)
> (gdb) bt
> #0 0x00007f1ffe318ea4 in mapi_seek_row (hdl=0x330c140, rownr=1, whence=0)
> at ../../../src/mapilib/Mapi.mx:4178
> #1 0x00007f1ffe542757 in SQLFetch_ (stmt=0x330c090)
> at ../../../../src/odbc/driver/SQLFetch.c:65
> #2 0x00007f1ffe542cfa in SQLFetch (hStmt=0x330c090)
> at ../../../../src/odbc/driver/SQLFetch.c:194
Did not find out yet what query it triggers.
----------------------------------------------------------------------
>Comment By: Stefan de Konink (skinkie)
Date: 2009-03-09 12:17
Message:
0x00007f5a9582eea4 in mapi_seek_row (hdl=0x13b54d0, rownr=1, whence=0) at
../../../src/mapilib/Mapi.mx:4178
4178 if (rownr > result->row_count && hdl->mid->active &&
read_into_cache(hdl->mid->active, 0) != MOK)
(gdb) print *result
Cannot access memory at address 0x0
(gdb) bt
#0 0x00007f5a9582eea4 in mapi_seek_row (hdl=0x13b54d0, rownr=1, whence=0)
at ../../../src/mapilib/Mapi.mx:4178
#1 0x00007f5a95a58757 in SQLFetch_ (stmt=0x13b5420) at
../../../../src/odbc/driver/SQLFetch.c:65
#2 0x00007f5a95a58cfa in SQLFetch (hStmt=0x13b5420) at
../../../../src/odbc/driver/SQLFetch.c:194
#3 0x00007f5a975ed41b in SQLFetch () from /usr/lib/libodbc.so.1
#4 0x0000000000524490 in ?? ()
#5 0x00000000006536fd in ?? ()
#6 0x000000000063eefc in execute ()
#7 0x0000000000653016 in ?? ()
#8 0x000000000063eefc in execute ()
#9 0x0000000000653016 in ?? ()
#10 0x000000000063eefc in execute ()
#11 0x0000000000653016 in ?? ()
#12 0x000000000063eefc in execute ()
#13 0x0000000000653016 in ?? ()
#14 0x000000000063eefc in execute ()
#15 0x000000000061be0b in zend_execute_scripts ()
#16 0x00000000005d85aa in php_execute_script ()
#17 0x0000000000691a45 in main ()
----------------------------------------------------------------------
Comment By: Stefan de Konink (skinkie)
Date: 2009-03-07 16:44
Message:
I also thing I found the problem in Mapi.mx
That one seems perfectly fine;
if (rownr < 0 || rownr > result->row_count)
return mapi_setError(hdl->mid, "Illegal row number",
"mapi_seek_row", MERROR);
One line above it:
if (rownr > result->row_count && hdl->mid->active &&
read_into_cache(hdl->mid->active, 0) != MOK)
return MERROR;
Now how is it possible that the requested row number is HIGHER than the
amount of rows in our result? It doesn't make any sense. Now I have solved
my bug by changing > to <=; but after review the code why not swap the
lines around, and remove the comparison at all?
if (rownr < 0 || rownr > result->row_count)
return mapi_setError(hdl->mid, "Illegal row number",
"mapi_seek_row", MERROR);
if (hdl->mid->active && read_into_cache(hdl->mid->active, 0) !=
MOK)
return MERROR;
----------------------------------------------------------------------
Comment By: Stefan de Konink (skinkie)
Date: 2009-03-07 14:40
Message:
I have reduced the problem to the following lines within phpBB;
while ($row = $db->sql_fetchrow($result))
{
$search->index('post', $row['post_id'],
$row['post_text'], $row['post_subject'], $row['poster_id'],
$row['forum_id']);
}
As you can see in the output the last function that 'works' is the DELETE;
That is equal to the final function in the index function. If I place an
exit; direct after the index function, everything works as expected. The
problem seems to be the next fetch row in the iteration.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2671445&group_id=56967
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
