[ic] Can't delete items from UI except as superuser, causes 500

[interchange-users@icdevgroup.org (frEEk)]

This problem was actually noticed not on Items, but on a partial copy of 
the flex editor as used under the Admin -> Tables area, used to manage 
an "Articles" section of the site. I can create and edit articles/items 
just fine, but attempting to delete one causes an Internal Server Error, 
and the item is not deleted. Nowever, everything works fine as a 
superuser. it's only as a regular user that the 500 occurrs. Customers 
can be deleted fine however. After 2 days of working on this problems, 
and debugging/reverse engineering thru what felt like 100 layers of 
subroutines, I have narrowed it down to the _hole_call_sv method of 
Safe::Hole.pm. Unfortunately, I cannot debug past that as it is compiled 
C code. In short, the Safe::Hole::call method simply calls 
_hole_call_sv, which in turn calls Vend::Tag, which calls Vend::Parse, 
which runs the usertag in question (successfully), returns to Vend::Tag, 
which returns to Safe::Hole. Before returning, _hole_call_sv calls 
itself (or more accurately Safe::Hole::call) once or twice more 
(successfully, and there seems to be no pattern as to it calling once or 
twice), but then the thread dies. No more lines in the error log from 
any of the Vend modules (almost all debug statements are uncommented). 
In short, the error appears to be happening somewhere after the usertag 
returns, but before the surrounding Safe::Hole::_hole_call_sv returns.

Perhaps more importantly, the line that causes a problem is 
$Tag->if_mm('!tables', "$t=d") in db_maintenance. returning after that 
line (on either resulting branch) leaves the 500, returning just before 
it gets the delete running just fine. The installation if IC is pretty 
much unmolested except for the addition of this copy of the flex editor. 
I expected it may be my changes causeing the problem until we noticed 
the same thing happening for Items. The user for which this error 
occurrs has full permissions on the relevant tables. I have edited the 
tag to read the more common $Tag->if_mm('!tables','=d') to no avail, as 
well as several other modifications.

Sorry if this sounds rediculously convoluted and badly explained. After 
following (often recursive) break marks thru this package for 2 days and 
having read half the maillist archives and docs i can only think in 
terms of interchange code and have forgotten how to communicate with 
humans. that & i think i'm going insane. really hoping someone has had 
the same problem before and can point me in the write direction. i saw 
what appeared to be the same problem over a year ago, but it was related 
to a missing flag tag which is a problem long since corrected.

Using IC 4.8.6 with mysql 3.23.51 on redhat 7.3

please...somebody save what little is left of my sanity.

thanks