Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Critical
-
Resolution: Won't Fix
-
Affects Version/s: 1.2
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
The result of my saga of testing with Lobo seems to be that the "é" character (e with accent, or alt + 0122 in windows) crashes the search function in CiviCRM, destroying the session of the current user if she/he tries to search. Here are some copied background e-mails for the record.
-Jesse
jesse@idcwebdev.com
Hey lobo,
I am able to replicate the problem on my box when entering the name "Renée Lepreau" through the standalone form. On additional error I encountered was getting a "URI too large" error from apache when trying to search contacts after signing up that contact through the standalone form. It didn't reappear after showing up once though. Otherwise the symptons were the same.
Actually, it looks like entering "Renée Lepreau" even through the normal interface causes this problem. Hmmmm. Further testing: looks like it is a general problem with the "é" character.
Entering other names/info works fine (doesn't look like the standalone form checks matching fields for duplicates though, dunno if that is intentional).
I'll file a bug report now that it is clear what's up.
-Jesse
1. jesse is running php 4.3.10 and mysql 4.1.9
2. his db size was quite small (< 50 contacts).
3. the code was working properly, however contact #28
was a french name (Renee (with an accent)).
4. Any search that matched contact #28 would put the
session in bad state, and subsequently all requests
would crash apache (pretty much after sess_read for
the technially curious folks)
5. deleting that contact fixed the issue (jesse: would
be great if u can enter the same contact from the web
interface and reproduce the issue)
6. i tried reproducing the isse on my local box with
php4 / php5 and mysql_40 / _41 files and did not
succeed
lobo
Hey everybody, another update:
Lobo was able to poke around a little bit again, and eventually suggested just deleting the contact (the one entered through the standalone form that triggered this saga) from the appropriate CiviCRM db tables. This solved the problem and now the database appears to be working. I haven't tried the standalone form yet, but will do so soon.
We didn't come to a clear diagnosis about what was going on. I gave Lobo a partial database dump and maybe he'll be able to figure it out.
It's great to have such involved support on an open source project! This has been evident to me all along. It's an incredibly strong reason to keep recommending CiviCRM to new clients.
-Jesse Mortenson
IDC WebDev
Update: I worked with Lobo for a while and we concluded that CiviCRM was not the problem. However, after getting my site back online it turns out that Node_Privacy_Byrole and Volunteer were just side effects of some larger problem with sessions. It seems to me that CiviCRM is the persistent problem, though I am unclear as to what mechanism trigged this effect.
I can now reproduce the original error on my site. Search doesn't work, once I try searching for contacts, it kills apache, producing errors like this in the apache log:
[Thu Nov 10 01:11:22 2005] [notice] child pid 30963 exit signal Segmentation fa\
ult (11)
[Thu Nov 10 01:11:25 2005] [notice] child pid 30965 exit signal Segmentation fa\
ult (11)
[Thu Nov 10 01:11:26 2005] [notice] child pid 30961 exit signal Segmentation fa\
ult (11)
At that point whatever user I logged in with can no longer access the site. Anonymous user concurrently seems to be fine. Once I clear out the sessions file (DELETE FROM sessions), I can re-log in as the original user and the site works fine (until I go into CiviCRM and try searching again). All of this is with or without node_privacy_byrole, and with lots of other modules turned off.
Only the "search" action in CiviCRM initiates the problem from what I can tell.
Let me know if there is a way to recover data/custom fields. Lobo - I think it might be best to wait until I'm available to help recover the site before taking another crack at the problem. I'll try to catch you on IRC.
-Jesse
IDC WebDev
Hey folks,
I'm slightly concerned that my copy of CiviCRM (1.2, included in Civicspace RC6) has broken after a strange error. I am writing here instead of filing a bug report to see if anybody knows of a quick fix for getting my database back online (in addition to solving the underlying problem).
I had an anonymous user fill out the standalone Profile form and get an access denied error (apparently when it was visiting some URL that included Profile in it). I assumed the error was from not having sufficient permissions to visit the User Profiles, so I granted that to anonymous users.
Then I reloaded the page request that had run into the Access Denied error, and that seemed to work (the anon. user was sent to the designated thank you page). However, going into CiviCRM afterwards I found that my search no longer works. It seems like I can individually search for all of the names in the database (and pull up results) EXCEPT for the user who just filled out the standalone form. I get nothing searching for that name. I also get nothing searching for all contacts (with a blank name field). I don't even get the "found no results" message.
I got a string of errors when I tried to do the first basic and the first advanced search right after the user filled out the form. The error looks like:
Location /index.php?q=civicrm/contact/search/basic&_qf_Search_display=true
array_key_exists(): The second argument should be either an array or an object in /var/www/green/www/modules/civicrm/CRM/Utils/System.php on line 322.
with two of these for good measure:
Location /index.php?q=civicrm/contact/search/basic&_qf_Search_display=true
Invalid argument supplied for foreach() in /var/www/green/www/modules/civicrm/CRM/Core/Form.php on line 154.
But no more errors occur on subsequent searches.
Do I need to excise a faulty entry? I don't have a ton of data in there yet, but I have my custom fields and profile fields, and a couple unique entries, so I don't want to blast it away if I can save it.
Using PHP 4.3 and mysql 4.1.
Thanks,
Jesse
IDC WebDev