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:27
Message:
(gdb) bt
#0 0x00007faee2200ea4 in mapi_seek_row (hdl=0x229fc90, rownr=1, whence=0)
at ../../../src/mapilib/Mapi.mx:4178
#1 0x00007faee242a757 in SQLFetch_ (stmt=0x229fbe0) at
../../../../src/odbc/driver/SQLFetch.c:65
#2 0x00007faee242acfa in SQLFetch (hStmt=0x229fbe0) at
../../../../src/odbc/driver/SQLFetch.c:194
#3 0x00007faee3d0d41b in SQLFetch () from /usr/lib/libodbc.so.1
#4 0x00000000004bf649 in php_odbc_fetch_hash (ht=<value optimized out>,
return_value=0x23077b8,
return_value_ptr=<value optimized out>, this_ptr=<value optimized
out>, return_value_used=<value optimized out>, result_type=2)
at /mnt/dv/skinkie/php-5.2.8/ext/odbc/php_odbc.c:1449
#5 0x00000000006741c9 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffecc5f4f0)
at /mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:200
#6 0x000000000065fe74 in execute (op_array=0x2226c38) at
/mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:92
#7 0x0000000000673b6d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffecc60520)
at /mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:234
#8 0x000000000065fe74 in execute (op_array=0x7faee2f99fc8) at
/mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:92
#9 0x0000000000673b6d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffecc60e90)
at /mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:234
#10 0x000000000065fe74 in execute (op_array=0x213d0a8) at
/mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:92
#11 0x0000000000673b6d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffecc61460)
at /mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:234
#12 0x000000000065fe74 in execute (op_array=0x1c7a1f0) at
/mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:92
#13 0x0000000000673b6d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffecc63f10)
at /mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:234
#14 0x000000000065fe74 in execute (op_array=0x1c6b038) at
/mnt/dv/skinkie/php-5.2.8/Zend/zend_vm_execute.h:92
#15 0x000000000063d671 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /mnt/dv/skinkie/php-5.2.8/Zend/zend.c:1134
#16 0x00000000005fb94d in php_execute_script (primary_file=0x7fffecc68660)
at /mnt/dv/skinkie/php-5.2.8/main/main.c:2023
#17 0x00000000006b1397 in main (argc=3, argv=0x7fffecc68858) at
/mnt/dv/skinkie/php-5.2.8/sapi/cgi/cgi_main.c:1989
----------------------------------------------------------------------
Comment By: Stefan de Konink (skinkie)
Date: 2009-03-09 12:19
Message:
(gdb) print *hdl
$1 = {mid = 0x13a5110, template = 0x0,
query = 0x13b6ef0 "SELECT post_id, post_subject, post_text, poster_id,
forum_id\n\t\t\tFROM phpbb_posts", maxbindings = 0,
bindings = 0x0, maxparams = 0, params = 0x0, result = 0x0, active = 0x0,
lastresult = 0x0, needmore = 0, pending_close = 0x0,
npending_close = 0, prev = 0x13b81e0, next = 0x0}
----------------------------------------------------------------------
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
