An ABF frame has a field with f8 format and tries to insert into the
same named field in a table that is of type f4 (it is not a scientific
application but lives in the pre-decimal type era), which results in a
buffer overflow and brings the whole installation down (II 9.3.1
(a64.lnx/106)NPTL)

The stack trace is revealing. If I interpreted it correctly (does the
dump of the Ingres stack follows the normal convention ? read from
bottom to the top ?)
The problem should be in the call of memcpy, which is considered
unsafe since it does not boundaries checking ?, hence an f8 overflows
an f4.

On second thought is should be a problem with the underlying C library
and not with Ingres

-----------BEGIN STACK TRACE------------
0: 414a5740 libc.so.6(memcpy+0x46) [0x3dae27bee6]( ... )
1: 414a5760 iidbms(qen_execute_cx+0x2e) [0x7cc719]( ... )
2: 414a5810 iidbms(qea_append+0x5a2) [0x7b0f92]( ... )
3: 414a6060 iidbms(qeq_query+0xe84) [0x4ea042]( ... )
4: 414a69a0 iidbms(qef_call+0xf5d) [0x4e337d]( ... )
5: 414a8fa0 iidbms(scs_sequencer+0x63aa) [0x489b4a]( ... )
6: 414b1130 iidbms(CSMT_setup+0x50e) [0x71134e]( ... )
-----------END STACK TRACE----------

::[58334 , 32035 , 00002aac6c97ae40,
scsqncr.c:15185 ]: Wed Jul 6 08:48:33 2011 E_SC0216_QEF_ERROR
Error returned by QEF.
::[58334 , 32035 , 00002aac6c97ae40,
scsqncr.c:15186 ]: Wed Jul 6 08:48:33 2011
E_SC0206_CANNOT_PROCESS An internal error prevents further processing
of this query.
Associated error messages which provide more detailed information
about the problem can be found in the error log, II_CONFIG:errlog.log
::[58334 , 32035 , 00002aac6c97ae40,
scsqncr.c:15186 ]: Query: Execute tr1
::[58334 , 32035 , 00002aac6c97ae40,
scsqncr.c:15186 ]: LQuery: Execute tr1
::[58334 , 32035 , 00002aac6d016140, ulx.c:
295 ]: Wed Jul 6 09:05:05 2011 E_QE0002_INTERNAL_ERROR A
QEF internal error occurred.
Associated error messages which provide more detailed information
about the problem can be found in the error log (errlog.log)
::[58334 , 32035 , 00002aac6d016140,
scssvc.c:920 ]: An error occurred in the following session:
::[58334 , 32035 , 00002aac6d016140, sc0e.c:
641 ]: >>>>>Session 00002AAC6D016140:1095440704<<<<<
::[58334 , 32035 , 00002aac6d016140,
sc0e.c:641 ]: Application Code: 00000000
Current Facility: QEF (00000006)
::[58334 , 32035 , 00002aac6d016140,
sc0e.c:641 ]: Client

::[58334 , 32035 , 00002aac6d016140, sc0e.c:
641 ]: Description:
::[58334 , 32035 , 00002aac6d016140,
sc0e.c:641 ]: Query: Execute tr1
::[58334 , 32035 , 00002aac6d016140, sc0e.c:
641 ]: Last Query: Execute tr1
::[58334 , 6d016140]: Wed Jul 6 09:05:05 2011 Segmentation
Violation (SIGSEGV) @PC 0000003dae27bee6
RSP 00000000414a51e8 RBP 00000000414a5740 RSI 0000000000000000
RDI 00002aac6d2b3cf3 RAX 00002aac6d2b3cf3 RBX 0000000000000000
RCX 0000000000000001 RDX 0000000000000008

Making the types match made the error disappear, but what to do in
this case ? should the underlying C code call a safe function rather
than memcpy ?
(well that is if I am interpreting this case correctly and the problem
does not lay elsewhere)

On Jul 8, 2011, at 5:56 AM, nikosv wrote:

I guess this is a REPEATED query? is the cache_dynamic DBMS
parameter turned ON in the config.dat?

I've seen this sort of thing with cache_dynamic ON, caused by insufficient
length checking in the parser. An ordinary REPEATED query ought to
behave itself. The cache_dynamic bug was fixed, I don't know in which build.

This is a server bug, either a row buffer was incorrectly allocated, or
a MOVE operation was compiled with the wrong length. The stack
trace is a bit weird, though, I'd expect to see ade_execute_cx above
qen_execute_cx. I'm going to suppose that it's a traceback glitch
and not the true state of affairs.

Karl

On Jul 8, 2:02*pm, Karl Schendel <schen... (AT) kbcomputer (DOT) com> wrote:
I cannot get back to you until Monday, if you would like to look into
it in more detail
But it is something along those lines :
The query is a simple insert with host variables like :
like insert into table (field1,field2) values (aram1,aram2);
field1 is f4, aram1 is f8
when that insert happens you get an error message that "data types are
incompatible" and the SIGSEV

On Jul 9, 7:14*am, nikosv <nikos... (AT) gmail (DOT) com> wrote:
ok managed to take another look at it today.cache_dynamic is off
I include the setup parameters taken from the error log :
(Also please let me know if the Ingres stack is read bottom-up or top-
down)

E_CL2530_CS_PARAM active_limit = 256
E_CL2530_CS_PARAM connect_limit = 256
E_CL2530_CS_PARAM cpu_statistics = OFF
E_CL2530_CS_PARAM define_address = OFF
E_CL2530_CS_PARAM unix_priority = 0
E_CL2530_CS_PARAM quantum_size = 1000
E_CL2530_CS_PARAM session_accounting = OFF
E_CL2530_CS_PARAM stack_size = 262144
E_CL2530_CS_PARAM stack_caching = OFF
E_CL2530_CS_PARAM server_class = INGRES
E_CL2530_CS_PARAM size_io_buf = 32768
E_CL2530_CS_PARAM cache_sharing = OFF
E_CL2530_CS_PARAM cache_name = cach_def
E_CL2530_CS_PARAM dmf_cache_size = 10000
E_CL2530_CS_PARAM dmf_free_limit = 312
E_CL2530_CS_PARAM dmf_group_count = 1500
E_CL2530_CS_PARAM dmf_group_size = 8
E_CL2530_CS_PARAM dmf_modify_limit = 7500
E_CL2530_CS_PARAM dmf_wb_end = 3000
E_CL2530_CS_PARAM dmf_wb_start = 5000
E_CL2530_CS_PARAM dmf_write_behind = ON
E_CL2530_CS_PARAM p4k_status = ON
E_CL2530_CS_PARAM dmf_cache_size = 7500
E_CL2530_CS_PARAM dmf_free_limit = 234
E_CL2530_CS_PARAM dmf_group_count = 900
E_CL2530_CS_PARAM dmf_group_size = 8
E_CL2530_CS_PARAM dmf_modify_limit = 5625
E_CL2530_CS_PARAM dmf_wb_end = 2250
E_CL2530_CS_PARAM dmf_wb_start = 3750
E_CL2530_CS_PARAM dmf_separate = OFF
E_CL2530_CS_PARAM dmf_write_behind = ON
E_CL2530_CS_PARAM p8k_status = ON
E_CL2530_CS_PARAM dmf_cache_size = 6000
E_CL2530_CS_PARAM dmf_free_limit = 188
E_CL2530_CS_PARAM dmf_group_count = 750
E_CL2530_CS_PARAM dmf_group_size = 8
E_CL2530_CS_PARAM dmf_modify_limit = 4500
E_CL2530_CS_PARAM dmf_wb_end = 1800
E_CL2530_CS_PARAM dmf_wb_start = 3000
E_CL2530_CS_PARAM dmf_separate = OFF
E_CL2530_CS_PARAM dmf_write_behind = ON
E_CL2530_CS_PARAM p16k_status = OFF
E_CL2530_CS_PARAM p32k_status = OFF
E_CL2530_CS_PARAM p64k_status = OFF
E_CL2530_CS_PARAM cache_lock = OFF
E_CL2530_CS_PARAM core_enabled = ON
E_CL2530_CS_PARAM cursor_limit = 16
E_CL2530_CS_PARAM database_limit = 257
E_CL2530_CS_PARAM database_list =
E_CL2530_CS_PARAM cursor_update_mode = DEFERRED
E_CL2530_CS_PARAM cursor_default_open = UPDATE
E_CL2530_CS_PARAM dmf_build_pages = 16
E_CL2530_CS_PARAM dmf_db_cache_size = 40
E_CL2530_CS_PARAM dmf_tbl_cache_size = 40
E_CL2530_CS_PARAM dmf_int_sort_size = 524288
E_CL2530_CS_PARAM dmf_tcb_limit = 5000
E_CL2530_CS_PARAM max_tuple_length = 2008
E_CL2530_CS_PARAM event_limit = 80
E_CL2530_CS_PARAM event_priority = 8
E_CL2530_CS_PARAM fast_commit = ON
E_CL2530_CS_PARAM gc_interval = 20
E_CL2530_CS_PARAM gc_num_ticks = 5
E_CL2530_CS_PARAM gc_threshold = 1
E_CL2530_CS_PARAM log_writer = 6
E_CL2530_CS_PARAM name_service = ON
E_CL2530_CS_PARAM default_journaling = ON
E_CL2530_CS_PARAM opf_active_limit = 51
E_CL2530_CS_PARAM opf_old_jcard = OFF
E_CL2530_CS_PARAM opf_old_cnf = OFF
E_CL2530_CS_PARAM opf_old_idxorder = OFF
E_CL2530_CS_PARAM opf_old_subsel = OFF
E_CL2530_CS_PARAM opf_memory = 23855104
E_CL2530_CS_PARAM opf_maxmemf = 50
E_CL2530_CS_PARAM opf_timeout_factor = 10
E_CL2530_CS_PARAM opf_stats_nostats_max = OFF
E_CL2530_CS_PARAM opf_hash_join = ON
E_CL2530_CS_PARAM opf_new_enum = ON
E_CL2530_CS_PARAM opf_pq_dop = 8
E_CL2530_CS_PARAM opf_pq_threshold = 1000
E_CL2530_CS_PARAM opf_pq_partthreads = 8
E_CL2530_CS_PARAM opf_stats_nostats_factor = 1
E_CL2530_CS_PARAM opf_greedy_factor = 1
E_CL2530_CS_PARAM opf_inlist_thresh = 18000
E_CL2530_CS_PARAM psf_memory = 17301504
E_CL2530_CS_PARAM psf_vch_prec = OFF
E_CL2530_CS_PARAM psf_maxmemf = 50
E_CL2530_CS_PARAM qef_dsh_memory = 65536000
E_CL2530_CS_PARAM qef_sort_mem = 1048576
E_CL2530_CS_PARAM qef_hash_mem = 20971520
E_CL2530_CS_PARAM qef_sorthash_memory = 815792128
E_CL2530_CS_PARAM qef_max_mem_sleep = 30
E_CL2530_CS_PARAM qflatten_aggregate = ON
E_CL2530_CS_PARAM qflatten_singleton = ON
E_CL2530_CS_PARAM query_flattening = ON
E_CL2530_CS_PARAM qsf_memory = 26214400
E_CL2530_CS_PARAM rdf_max_tbls = 400
E_CL2530_CS_PARAM rdf_memory = 11489280
E_CL2530_CS_PARAM rdf_col_defaults = 50
E_CL2530_CS_PARAM rdf_tbl_synonyms = 50
E_CL2530_CS_PARAM result_structure = heap
E_CL2530_CS_PARAM rule_depth = 20
E_CL2530_CS_PARAM rule_upd_prefetch = ON
E_CL2530_CS_PARAM scf_rows = 20
E_CL2530_CS_PARAM server_class = INGRES
E_CL2530_CS_PARAM sole_server = ON
E_CL2530_CS_PARAM ulm_chunk_size = 524288
E_CL2530_CS_PARAM session_check_interval = 30
E_CL2530_CS_PARAM system_readlock = shared
E_CL2530_CS_PARAM system_maxlocks = 50
E_CL2530_CS_PARAM system_timeout = 0
E_CL2530_CS_PARAM system_isolation = serializable
E_CL2530_CS_PARAM system_lock_level = default
E_CL2530_CS_PARAM log_readnolock = OFF
E_CL2530_CS_PARAM log_esc_lpr_sc = OFF
E_CL2530_CS_PARAM log_esc_lpr_ut = OFF
E_CL2530_CS_PARAM log_esc_lpt_sc = OFF
E_CL2530_CS_PARAM log_esc_lpt_ut = OFF
E_CL2530_CS_PARAM ambig_replace_64compat = OFF
E_CL2530_CS_PARAM rep_qman_threads = 1
E_CL2530_CS_PARAM rep_txq_size = 50
E_CL2530_CS_PARAM rep_sa_lockmode = user
E_CL2530_CS_PARAM rep_iq_lockmode = user
E_CL2530_CS_PARAM rep_dq_lockmode = page
E_CL2530_CS_PARAM rep_dt_maxlocks = 0
E_CL2530_CS_PARAM dmcm = OFF
E_CL2530_CS_PARAM default_page_size = 8192
E_CL2530_CS_PARAM blob_etab_structure = BTREE
E_CL2530_CS_PARAM psort_bsize = 1000
E_CL2530_CS_PARAM psort_rows = 10000
E_CL2530_CS_PARAM psort_nthreads = 2
E_CL2530_CS_PARAM pindex_bsize = 5000
E_CL2530_CS_PARAM pindex_nbuffers = 3
E_CL2530_CS_PARAM opf_joinop_timeout = 0
E_CL2530_CS_PARAM opf_timeout_abort = 0
E_CL2530_CS_PARAM blob_etab_page_size = 4096
E_CL2530_CS_PARAM rule_del_prefetch = ON
E_CL2530_CS_PARAM date_alias = ingresdate
E_CL2530_CS_PARAM table_auto_structure = OFF
E_CL2530_CS_PARAM cache_dynamic = OFF
E_CL2530_CS_PARAM qef_no_dependency_chk = OFF

On Jul 13, 2011, at 11:57 AM, nikosv wrote:


hmm, ok. Should be simple enough to reproduce with a small test
program, then. Has this ABF program been recompiled or at least
re-linked against the installed version of Ingres? This looks more like
a back-end problem than an ABF problem, but maybe ABF is doing
something strange to provoke it.

bottom up.

Karl

On Jul 13, 7:15*pm, Karl Schendel <schen... (AT) kbcomputer (DOT) com> wrote:
table's data type and recompiled.
After that there was no issue again
Note that there was another program with the same exact problem (f8 to
f4) that crashed the server as well, so that one was fixed too

Since the stack trace is bottom-up and the last call is in 'memcpy'
could be a case of buffer overflow?

On Jul 13, 2011, at 12:38 PM, nikosv wrote:
Well, yes, sort of. The server is executing a CX (compiled
expression), and is most likely executing an ADE_MECOPY
instruction, which is done via memcpy. Either the operands
generated for ADE_MECOPY are wrong, or the row area allocated
for the operands is wrong. The underlying cause is probably
something being done incorrectly in the type resolver, leading
to a garbage length somewhere, leading to a bad query plan,
leading to the segv. It could also be a bug in the query compiler
itself, although that's somewhat less likely given the simple
form of the query. It might even be something in ABF itself,
sending a bad length to the backend, but that seems very unlikely.

Karl