|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34705 udm_clear_search_limits() causes seg.fault.
Submitted: 2005-10-02 13:11 UTC Modified: 2006-07-15 14:34 UTC
From: tomasare at gmail dot com Assigned: pajoye (profile)
Status: Closed Package: mnoGoSearch related
PHP Version: 4CVS-2005-10-02 (snap) OS: Ubuntu GNU/Linux
Private report: No CVE-ID: None
 [2005-10-02 13:11 UTC] tomasare at gmail dot com
If you add some search limits (udm_add_search_limit()) and maybe some params (udm_set_agent_param()), and then clear the search limits with udm_clear_search_limits(), some of the params also gets cleared (i.e. they "disappear").  In addition all search limits may not actually be cleared and in the end the script seg.faults when executing udm_find().

Reproduce code:
udm_set_agent_param($agent, UDM_PARAM_QUERY, "foo");
udm_set_agent_param($agent, UDM_PARAM_WEIGHT_FACTOR, 222211);
udm_add_search_limit($agent, UDM_LIMIT_TAG, "%");

Expected result:
The script seg.faults when calling udm_find().

Actual result:
As far as I can see, the code for udm_clear_search_limits contains to errors:

1. Agent->Conf->Vars.nvars gets decreased inside the loop.  This causes the loop to iterate fewer times than expected.  That means that some of the search limits may not be cleared.

2. After the loop is done, it contains some NULL-values (from the cleared limits).  Since the Agent->Conf->Vars.nvars is reduced, some params after these NULL-values may not be visible.

These NULL-bytes may cause a seg.fault at line 1998 in searchtool.c (from the mnogosearch source).

I made a "quick and dirty" solution that's available here:
It modifies the Agent->Conf->Vars.nvars only after the loop, and after first sorting the array to remove any "holes" caused by the NULL-values.

This is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1082341088 (LWP 20149)]
0x40776e09 in strcasecmp () from /lib/tls/
(gdb) bt
#0  0x40776e09 in strcasecmp () from /lib/tls/
#1  0x4068ab5e in UdmConvert (Conf=0x84c93d0, Res=0x83e0010, lcs=0x845ca7c, bcs=0x406f6160) at searchtool.c:2011
#2  0x40696baf in UdmFind (A=0x84cd4e0) at db.c:946
#3  0x080e4491 in zif_udm_find (ht=1082341068, return_value=0x83e013c, this_ptr=0x0, return_value_used=1)
    at /usr/local/src/php-4.4.0/ext/mnogosearch/php_mnogo.c:2030
#4  0x081ab45d in execute (op_array=0x83d895c) at /usr/local/src/php-4.4.0/Zend/zend_execute.c:1672
#5  0x0819cc79 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.4.0/Zend/zend.c:938
#6  0x0817340d in php_execute_script (primary_file=0xbffffa30) at /usr/local/src/php-4.4.0/main/main.c:1751
#7  0x081afd17 in main (argc=2, argv=0xbffffaf4) at /usr/local/src/php-4.4.0/sapi/cli/php_cli.c:828


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-03 16:01 UTC]
Assigned to the maintainer.
 [2005-10-03 18:49 UTC]
It is the function call used in old versions of mnogosearch.
It seems to me that the best and the most safe way is to disable this function if php compiled with mnogosearch-3.2+
 [2005-10-03 21:03 UTC] tomasare at gmail dot com
This bug report was produced using mnogosearch-3.2.34 and php-4.4.0.
 [2005-10-03 21:10 UTC]
gluke at
For PECL - maybe it'd be the best way.
But removing/disabling functions in PHP4 and others doesn't seem to be the best option.
I'd suggest to make a wrapper to emulate the old syntax using new functions (not sure if it's possible, though).
 [2006-07-15 14:34 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

I fixed it in PECL by disabling the function when the extension is built against 3.2+

I'll release a very first PECL version today. Please report any further bugs here:
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Aug 12 16:01:25 2020 UTC