Hello.
I have been unable to make the zoom link work; it returns after a second
or two with an apache "internal server error" message. In the log file, I
see the following:
OTRS-CGI-10[568842]: [Error][Kernel::Modules::AgentZoom::Run][Line:163]:
Out of memory. Restart daemon and try again (needed 65528 bytes), SQL:
'SELECT sa.id, st.tn, sa.a_from, sa.a_to, sa.a_cc, sa.a_subject,
sa.a_body, st.create_time_unix, st.tn, st.user_id, st.ticket_state_id,
st.ticket_priority_id, sa.create_time, stt.name as sender_type, at.name
as article_type, su.login, sl.name as lock_type, sp.name as priority,
sp.id as priority_id, tsd.name as state, sa.content_path, sq.name as
queue, st.create_time as ticket_create_time, sa.a_freekey1,
sa.a_freetext1, sa.a_freekey2, sa.a_freetext2, sa.a_freekey3,
sa.a_freetext3, st.freekey1, st.freekey2, st.freetext1, st.freetext2,
st.customer_id, st.customer_user_id, sq.group_id, st.ticket_answered,
sq.escalation_time, sa.a_content_type, sa.incoming_time, st.until_time
FROM article sa, ticket st, article_sender_type stt, article_type at,
system_user su, ticket_lock_type sl, ticket_priority sp, ticket_state
tsd, queue sq WHERE sa.ticket_id = st.id
If I try and run that query by hand, the mysql server starts to consume
many megabytes of memory and eventually dies.
I established that "SELECT sa.id FROM article sa, ticket st WHERE
sa.ticket_id = st.id" returns immediately, and with the expected result.
Today I upgraded from mysql-3.23.57 to 4.0.14. Now the mysql server dies
(and is restarted by mysqld_safe) upon receiving that request:
OTRS-CGI-10[571691]: [Error][Kernel::Modules::AgentZoom::Run][Line:163]:
Lost connection to MySQL server during query, SQL: 'SELECT sa.id, ...
Only on Friday I reinstalled the entire OTRS system (including erasing and
re-initialising the database) during an upgrade to 1.1.3. 1.1.2 suffered
from the same problem.
The apache webserver is 1.3.28. Perl is 5.6.0. OS is IRIX 6.5.20m.
The database runs on linux 2.4.21, and is mysql-4.0.14.
Any clues would be greatly appreciated!
Best,
Al.
PS: mysql.err says:
thd=0x8805a78
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbe7fedd8, backtrace may not be correct.
0x80e2edf handle_segfault + 423
0x40036144 _end + 935093244
0x8109629 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UlP13select_result + 6921
0x8115d33 handle_select__FP3THDP6st_lexP13select_result + 95
0x80eed38 mysql_execute_command__Fv + 976
0x80f26d5 mysql_parse__FP3THDPcUi + 565
0x80edec9 dispatch_command__F19enum_server_commandP3THDPcUi + 1461
0x80f3bfd do_command__FP3THD + 153
0x80ed14e handle_one_connection + 634
0x4003310c _end + 935080900
0x401d160a _end + 936777922
New value of fp=(nil) failed sanity check, terminating stack trace!
thd->query at 0x8853610 = SELECT sa.id, st.tn, sa.a_from, sa.a_to,
sa.a_cc, sa.a_subject, sa.a_body, st.create_time_unix, st.tn, st.user_id,
st.ticket_state_id, st.ticket_priority_id, sa.create_time, stt.name as
sender_type, at.name as article_type, su.login, sl.name as lock_type,
sp.name as priority, sp.id as priority_id, tsd.name as state,
sa.content_path, sq.name as queue, st.create_time as ticket_create_time,
sa.a_freekey1, sa.a_freetext1, sa.a_freekey2, sa.a_freetext2,
sa.a_freekey3, sa.a_freetext3, st.freekey1, st.freekey2, st.freetext1,
st.freetext2, st.customer_id, st.customer_user_id, sq.group_id,
st.ticket_answered, sq.escalation_time, sa.a_content_type,
sa.incoming_time, st.until_time FROM article sa, ticket st,
article_sender_type stt, article_type at, system_user su, ticket_lock_type
sl, ticket_priority sp, ticket_state tsd, queue sq WHERE sa.ticket_id =
st.id AND sq.id = st.queue_id AND stt.id = sa.article_sender_type_id AND
at.id = sa.article_type_id AND sp.id = st.ticket_priority_id AND sl.id =
