Segmentation fault detected (SIGSEGV) in map_match_str_col_str_val_uidx_val (RESOLVED

[kuonirat]

Please, wait a moment, I'm reproducing the error.

[kuonirat]

Hi!

This:

drop table t;

create table t (
  status int NOT NULL default '0',
  args varchar(8192) NOT NULL
) with structure = vectorwise;

copy table t (
    status = 'c0tab',
    args = 'c0nl'
) from 'data.csv';

SELECT FIRST 1 args, LOCATE('text', args) as i
FROM t
WHERE status = '99'

\g

makes "VectorWise server network communication error" with these error details from vectorwise.log:

2010-07-28 12:11:34 PID  2496: INFO:X100SERVER:received query: [Window (Project (Select (MScan ( _t = '_t', [ '_status', '_args'] ) [ 'est_card' = '1' ] , ==(_t._status, sint('99')))  [ 'est_card' = '1' ] , [_t._args, _i = locate( str('text'),_t._args)] ), [0, 1])]
2010-07-28 12:11:34 PID  2496: WARN:GetPrimDesc: signature map_locate_str_val_str_col_uidx_val not found
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER:Segmentation fault detected (SIGSEGV). System shutting down.
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER:SIGSEGV trace:
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(server_quit+0x1c7) [0x7fa55a558b47]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /lib/libpthread.so.0 [0x7fa55935ca80]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(map_match_str_col_str_val_uidx_val+0x5c) [0x7fa55a295834]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(map_locate_str_col_str_val_uidx_val+0x1a2) [0x7fa55a296236]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(MapValFcn+0x1f8) [0x7fa559c585f8]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(expr_eval+0x14f2) [0x7fa559c5a556]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(project_next+0x81) [0x7fa55a3acdf9]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0 [0x7fa55a3b6101]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /opt/Ingres/IngresVW/ingres/lib/libx100.so.0(handle_request+0x6d6) [0x7fa55a55a56e]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /lib/libpthread.so.0 [0x7fa559354fc7]
2010-07-28 12:11:34 PID  2496:ERROR:X100SERVER: in /lib/libc.so.6(clone+0x6d) [0x7fa558e4759d]

I'm attaching the sample data.

Best regards!

[kuonirat]

Workaround is to use POSITION function instead of LOCATE, with all it's limitations.

[kuonirat]

No, POSITION() also makes the exact same error, but in different cases.

[makni01]

Thank you Konrad for the report, 903 has been opened.

[marcin]

Hi Konrad,

Sorry about your problems, but thanks for keeping us busy

m.

[peterboncz]

Hi Konrad,

Your use of LOCATE (and position) is unexpected; now you are looking whether your data occurs in the string 'text'; and it does in no such case.

Ingres VectorWise is currently not optimized (vectorized) for this unexpected use of the LOCATE/POSITION functions; and this is why the signature warning appeared in the vectorwise.log. But, there was a bug in the fall-back mechanism that then evaluates the function one tuple-at-a-time (slow). Fix for 903 has been committed.

But, as said, you can avoid the problem by swapping the parameters, as you probably intended anyway.

Peter

[Bodo]

Peter,
what is "unexpeceted" at the use of the LOCATE function in this query (though I assume Konrad wanted the parameters rather the other way around)?
The definition of locate(c1, c2) in the SQL Reference Guide says what should be returned if c2 is not found: the function returns size(c1) + 1.
So, in this case it should return 5, if the content of column arg was not found in the string "text".

[peterboncz]

Hi Bob,

I truly believe that the most frequent use case of the LOCATE() and POSITION() functions is to look for the occurence of a certain fixed substring in a database column (expression); and I also believe this was Konrad's intention when he found this bug.

Searching whether a database column is a substring of some fixed string also works, as well as the case where both the string to look for and the string to look in are a column (expression). But, the point is that these are currently not (or less) optimized than the case where we look for a single string in a column (expression).

Now that we are on this topic, LIKE handling in Ingres VectorWise in fact *only* works when the LIKE pattern is a constant expression. I am sure Ingres VectorWise is not the only database system with such a restriction. LIKE handling in Ingres VectorWise is highly optimized (especially on CPUs that support SSE4.2) ; but these optimizations require a constant string pattern to look for. In case of LIKE, there is not yet a slowpath fall-back implementation for non-constant patterns (but for LOCATE/POSITION there is - only it was broken, as Konrad discovered).

Peter

BTW
Konrad, as a workaround to a previous bug we had asked you to disable the use of SSE4.2 instructions in the vectorwise.conf file. As this problem has been fixed a few builds back already, you can switch it back on, and LIKE/POSITION/etc string handling will become faster, again.

[kuonirat]

Originally Posted by peterboncz

But, as said, you can avoid the problem by swapping the parameters, as you probably intended anyway.

Thanks for this suggestion. It seems that the parameters order is different for LOCATE() and POSITION() functions, which is not clearly explained in the Ingres SQL Reference Guide.

Originally Posted by Bodo

The definition of locate(c1, c2) in the SQL Reference Guide says what should be returned if c2 is not found: the function returns size(c1) + 1.

Bodo, Your suggestion led me to another bug in the SIZE() implementation: http://community.ingres.com/forum/ve...ze-result.html

I've also discovered another bug with POSITION() function: http://community.ingres.com/forum/ve...-overflow.html