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 =