Bugs item #2855021, was opened at 2009-09-09 10:23
Message generated for change (Settings changed) made by mr-meltdown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2855021&group_id=56967

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SQL/Core
Group: SQL CVS Head
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stefan de Konink (skinkie)
Assigned to: Niels Nes (nielsnes)
>Summary: SQL: mserver accepts sql connections before scenario load

Initial Comment:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2f6ae60910 (LWP 27586)]
0x00007f2f6b0f6b02 in scanner_query_processed (s=0x2a7d008)
    at ../../../src/server/sql_scan.mx:429
429             cur = s->rs->buf[s->rs->pos];
(gdb) bt
#0  0x00007f2f6b0f6b02 in scanner_query_processed (s=0x2a7d008)
    at ../../../src/server/sql_scan.mx:429
#1  0x00007f2f6b08a3c8 in sqlcleanup (c=0x2a7afd8, err=0)
    at ../../../../src/backends/monet5/sql.mx:1296
#2  0x00007f2f6b0c6429 in SQLengineIntern (c=0x6057a8, be=0x7f2f64045018)
    at ../../../../src/backends/monet5/sql_scenario.mx:1236
#3  0x00007f2f6b0c6a50 in SQLengine (c=0x6057a8)
    at ../../../../src/backends/monet5/sql_scenario.mx:1367
#4  0x00007f2f7cec2f85 in runPhase (c=0x6057a8, phase=4)
    at ../../../src/mal/mal_scenario.mx:602
#5  0x00007f2f7cec3121 in runScenarioBody (c=0x6057a8)
    at ../../../src/mal/mal_scenario.mx:648
#6  0x00007f2f7cec32e1 in runScenario (c=0x6057a8)
    at ../../../src/mal/mal_scenario.mx:672
#7  0x00007f2f7ce7a185 in MSserveClient (dummy=0x6057a8)
    at ../../../src/mal/mal_session.mx:496
#8  0x00007f2f7c69c1f2 in wrapper_routine (data=0x7f2f6b5f9c40)
    at ../../../src/gdk/gdk_posix.mx:983
#9  0x00007f2f7b390624 in start_thread () from /lib/libpthread.so.0
#10 0x00007f2f7a4ba56d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()


Lets say what I did to create it was the following; I was working on an insert 
script which worked as a charm:
sh station.sh | /opt/monetdb-head/bin/mclient -lsql /dev/stdin

After that I removed the /dev/stdin, (accidently pressed enter), and saw the 
SEGV above;

The query that comes out of the script is:
INSERT INTO O3 SELECT date, 107, station107 FROM (SELECT date, station107 FROM 
rivm_012000_O3 UNION ALL SELECT date, station107 FROM rivm_012001_O3 UNION ALL 
SELECT date, station107 FROM rivm_022000_O3 UNION ALL SELECT date, station107 
FROM rivm_022001_O3 UNION ALL SELECT date, station107 FROM rivm_032000_O3 UNION 
ALL SELECT date, station107 FROM rivm_032001_O3 UNION ALL SELECT date, 
station107 FROM rivm_042000_O3 UNION ALL SELECT date, station107 FROM 
rivm_042001_O3 UNION ALL SELECT date, station107 FROM rivm_052000_O3 UNION ALL 
SELECT date, station107 FROM rivm_052001_O3 UNION ALL SELECT date, station107 
FROM rivm_062000_O3 UNION ALL SELECT date, station107 FROM rivm_062001_O3 UNION 
ALL SELECT date, station107 FROM rivm_072000_O3 UNION ALL SELECT date, 
station107 FROM rivm_072001_O3 UNION ALL SELECT date, station107 FROM 
rivm_082000_O3 UNION ALL SELECT date, station107 FROM rivm_082001_O3 UNION ALL 
SELECT date, station107 FROM rivm_092000_O3 UNION ALL SELECT date, station107 
FROM rivm_092001_O3 UNION ALL SELECT date, station107 FROM rivm_102000_O3 UNION 
ALL SELECT date, station107 FROM rivm_102001_O3 UNION ALL SELECT date, 
station107 FROM rivm_112000_O3 UNION ALL SELECT date, station107 FROM 
rivm_112001_O3 UNION ALL SELECT date, station107 FROM rivm_122000_O3 UNION ALL 
SELECT date, station107 FROM rivm_122001_O3 UNION ALL SELECT date, station107 
FROM rivm_apr_2002_O3 UNION ALL SELECT date, station107 FROM rivm_april2003_O3 
UNION ALL SELECT date, station107 FROM rivm_april2004_O3 UNION ALL SELECT date, 
station107 FROM rivm_april2005_O3 UNION ALL SELECT date, station107 FROM 
rivm_april2006_O3 UNION ALL SELECT date, station107 FROM rivm_april2007_O3 
UNION ALL SELECT date, station107 FROM rivm_april2008_O3 UNION ALL SELECT date, 
station107 FROM rivm_april2009_O3 UNION ALL SELECT date, station107 FROM 
rivm_aug_2002_O3 UNION ALL SELECT date, station107 FROM rivm_augustus2003_O3 
UNION ALL SELECT date, station107 FROM rivm_augustus2004_O3 UNION ALL SELECT 
date, station107 FROM rivm_augustus2005_O3 UNION ALL SELECT date, station107 
FROM rivm_augustus2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_augustus2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_augustus2008_O3 UNION ALL SELECT date, station107 FROM rivm_dec_2002_O3 
UNION ALL SELECT date, station107 FROM rivm_december2003_O3 UNION ALL SELECT 
date, station107 FROM rivm_december2004_O3 UNION ALL SELECT date, station107 
FROM rivm_december2005_O3 UNION ALL SELECT date, station107 FROM 
rivm_december2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_december2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_december2008_O3 UNION ALL SELECT date, station107 FROM rivm_feb_2002_O3 
UNION ALL SELECT date, station107 FROM rivm_februari2004_O3 UNION ALL SELECT 
date, station107 FROM rivm_februari2005_O3 UNION ALL SELECT date, station107 
FROM rivm_februari2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_februari2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_februari2008_O3 UNION ALL SELECT date, station107 FROM 
rivm_februari2009_O3 UNION ALL SELECT date, station107 FROM rivm_jan_2002_O3 
UNION ALL SELECT date, station107 FROM rivm_januari2004_O3 UNION ALL SELECT 
date, station107 FROM rivm_januari2005_O3 UNION ALL SELECT date, station107 
FROM rivm_januari2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_januari2007_O3 UNION ALL SELECT date, station107 FROM rivm_januari2008_O3 
UNION ALL SELECT date, station107 FROM rivm_januari2009_O3 UNION ALL SELECT 
date, station107 FROM rivm_jul_2002_O3 UNION ALL SELECT date, station107 FROM 
rivm_juli2003_O3 UNION ALL SELECT date, station107 FROM rivm_juli2004_O3 UNION 
ALL SELECT date, station107 FROM rivm_juli2005_O3 UNION ALL SELECT date, 
station107 FROM rivm_juli2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_juli2007_O3 UNION ALL SELECT date, station107 FROM rivm_juli2008_O3 UNION 
ALL SELECT date, station107 FROM rivm_jun_2002_O3 UNION ALL SELECT date, 
station107 FROM rivm_juni2003_O3 UNION ALL SELECT date, station107 FROM 
rivm_juni2004_O3 UNION ALL SELECT date, station107 FROM rivm_juni2005_O3 UNION 
ALL SELECT date, station107 FROM rivm_juni2006_O3 UNION ALL SELECT date, 
station107 FROM rivm_juni2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_juni2008_O3 UNION ALL SELECT date, station107 FROM rivm_maart2004_O3 UNION 
ALL SELECT date, station107 FROM rivm_maart2005_O3 UNION ALL SELECT date, 
station107 FROM rivm_maart2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_maart2007_O3 UNION ALL SELECT date, station107 FROM rivm_maart2008_O3 
UNION ALL SELECT date, station107 FROM rivm_maart2009_O3 UNION ALL SELECT date, 
station107 FROM rivm_mei_2002_O3 UNION ALL SELECT date, station107 FROM 
rivm_mei2003_O3 UNION ALL SELECT date, station107 FROM rivm_mei2004_O3 UNION 
ALL SELECT date, station107 FROM rivm_mei2005_O3 UNION ALL SELECT date, 
station107 FROM rivm_mei2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_mei2007_O3 UNION ALL SELECT date, station107 FROM rivm_mei2008_O3 UNION 
ALL SELECT date, station107 FROM rivm_mei2009_O3 UNION ALL SELECT date, 
station107 FROM rivm_mrt_2002_O3 UNION ALL SELECT date, station107 FROM 
rivm_nov_2002_O3 UNION ALL SELECT date, station107 FROM rivm_november2003_O3 
UNION ALL SELECT date, station107 FROM rivm_november2004_O3 UNION ALL SELECT 
date, station107 FROM rivm_november2005_O3 UNION ALL SELECT date, station107 
FROM rivm_november2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_november2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_november2008_O3 UNION ALL SELECT date, station107 FROM rivm_okt_2002_O3 
UNION ALL SELECT date, station107 FROM rivm_oktober2003_O3 UNION ALL SELECT 
date, station107 FROM rivm_oktober2004_O3 UNION ALL SELECT date, station107 
FROM rivm_oktober2005_O3 UNION ALL SELECT date, station107 FROM 
rivm_oktober2006_O3 UNION ALL SELECT date, station107 FROM rivm_oktober2007_O3 
UNION ALL SELECT date, station107 FROM rivm_oktober2008_O3 UNION ALL SELECT 
date, station107 FROM rivm_sep_2002_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2003_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2004_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2005_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2006_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2007_O3 UNION ALL SELECT date, station107 FROM 
rivm_september2008_O3) as x WHERE station107 IS NOT NULL ORDER BY date;

...rather innocent and normally completely working.

----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-09-09 10:59

Message:
I just checked before my last reply if it would normally work if I actively
looked for a >. Indeed that works.

"# MonetDB/SQL module v2.33.0 loaded"
Is visible before the > appears.

And regarding to the bug in one; I think it is a bit odd that the actual
loading now takes much longer than I have experienced before. I have 174
tables in my database, that is a bit more than usual ;)

----------------------------------------------------------------------

Comment By: Fabian (mr-meltdown)
Date: 2009-09-09 10:46

Message:
That feels like a bug exposed in merovingian a while ago.  You should only
connect after the sql scenario becomes available.  Not sure why it accepts
you before that though.  Does the bug happen if you wait long enough too? 
Or are we dealing with two bugs in one now?

----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-09-09 10:42

Message:
0x00007f74d7a10b02 in scanner_query_processed (s=0x35932c8) at
../../../src/server/sql_scan.mx:429
429             cur = s->rs->buf[s->rs->pos];
(gdb) print s->rs->pos
$1 = 1461
(gdb) print *s->rs->buf[s->rs->pos]
Cannot access memory at address 0xb6a
(gdb) print s->rs->buf[s->rs->pos]
Cannot access memory at address 0xb6a
(gdb) print s->rs      
$2 = (bstream *) 0x3590900
(gdb) print *s->rs
$3 = {s = 0x4ff, buf = 0x5b5 <Address 0x5b5 out of bounds>, size =
81737522629208, pos = 1461, len = 15842497851538791387, eof = -420114744,
mode = 32628}
(gdb) print *s->rs->buf
Cannot access memory at address 0x5b5
(gdb) print s->rs->buf
$4 = 0x5b5 <Address 0x5b5 out of bounds>
(gdb) print s->rs->pos
$5 = 1461

Key observation;
- Bug can be reproduced to connect to Monet *BEFORE* the > prompt is
there. So there is an:
# Listening for connection requests on mapi:monetdb://127.0.0.1:50000/

- Mclient will reply:
Connection terminated

- Nuking data in after the > appears results in the segmentation fault.


Now I have identified a parental issue; the diplaying of the prompt take
ages regardeless of the fact I nicely stopped the server or it crashed. 

I'm not running vanilla...

----------------------------------------------------------------------

Comment By: Fabian (mr-meltdown)
Date: 2009-09-09 10:28

Message:
what are the values of s->rs, s->rs->buf, s->rs->pos

have you tried this on vanilla sources, or your modified ones?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2855021&group_id=56967

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs

Reply via email to