v0.11.0 server crash upon start about vsql

[elliotchance]

I wonder if this is a problem with the cross compilation on windows. I'm able use TablePlus with the following:

Elliots-MBP-2:vsql elliot$ v run cmd/vsql.v server -v test.vsql
ready on 127.0.0.1:3210
connected
query: SELECT version() FROM singlerow;
response: vsql.Result{
    columns: ['COL1']
    rows: [vsql.Row{
        offset: 0
        data: {'COL1': vsql.Value{
            typ: CHARACTER VARYING
            f64_value: 0
            string_value: 'PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit'
        }}
    }]
    elapsed_parse:     time.Duration(29725000)
    elapsed_exec:     time.Duration(66000)
    idx: 0
}
query: SELECT oid, typname FROM pg_type;
error: vsql.SQLState42P01: no such table: PG_TYPE
query: create table foo (x int);
error: vsql.SQLState42P07: duplicate table: FOO

Are you able to verify this for me? If so, I can update the GitHub build action to compile on windows for the windows binary.

[elliotchance]

Or, I wonder if the panic you're seeing (even though you get no backtrace) is actually because of this: https://discord.com/channels/592103645835821068/592118040179507207/883790387918024775

Either way, I'll have a fix coming shortly.

[michaeldesu]

Thanks - a quick update: I just tried the 0.11.1 release, and it's better (no panic).

With the .net client, I get the following message:

ErrorMessage: The given key was not present in the dictionary.

and the server reports:

vsql v0.11.1 2021-09-05
ready on 127.0.0.1:3210
connected

I will try this again later with tableplus and see how it differs. Thanks again!

[michaeldesu]

I've tried this latest release on my home PC, and regrettably Microsoft Defender is reporting the zip as containing a virus (Trojan:Script/Oneeva.A!ml - which it rates as 'Severe'). Seems like this might be a known false positive report, so I've overridden it.

I could connect ok using TablePlus, and I created a table and made some inserts, but the server crashed out a few times randomly, even at idle, e.g.

V panic: net: op timed out
v hash: 3fd2dd4
print_backtrace_skipping_top_frames_mingw is not implemented

[elliotchance]

I've tried this latest release on my home PC, and regrettably Microsoft Defender is reporting the zip as containing a virus (Trojan:Script/Oneeva.A!ml - which it rates as 'Severe'). Seems like this might be a known false positive report, so I've overridden it.

That's annoying. If you have V installed im curious if your compilation ends up reporting the same virus, or if it was a caused by mingw cross-compilation.

I could connect ok using TablePlus, and I created a table and made some inserts, but the server crashed out a few times randomly, even at idle, e.g.

I think the timeouts are caused by the pg protocol allowing messages to be sent asynchronously from both ends, but on the vsql side there's a lot of built in expectations of waiting for a particular message next. You can try running with the -v option to see what's actually happening.

[michaeldesu]

I'm having some trouble to compile/run it on my Windows machine (having just installed the latest compiler from the V home page and testing a simple hello-world to ensure it works).

When I compile it like your suggestion above I get the following output - please guide me & I'll try again:

C:\Users\micha\Documents\~projects\v\vsql-main>v run cmd\vsql.v server -v test.vsql
vsql MISSING_VERSION
Unhandled Exception 0xC00000FD
C:/Users/micha/AppData/Local/Temp/v/vsql.3297434294738061661.tmp.c:10964: at print_backtrace_skipping_top_frames_tcc: Backtrace
C:/Users/micha/AppData/Local/Temp/v/vsql.3297434294738061661.tmp.c:10931: by print_backtrace_skipping_top_frames
C:/Users/micha/AppData/Local/Temp/v/vsql.3297434294738061661.tmp.c:10989: by unhandled_exception_handler
7ffdf6228a4c : by ???
0058fb68 : at ???: RUNTIME ERROR: stack overflow
C:/Users/micha/AppData/Local/Temp/v/vsql.3297434294738061661.tmp.c:27707: by vsql__parse_ast

[elliotchance]

Hm, that's a shame. I don't think this will help, but make sure you have the real latest version of v by using:

v up

If you're feeling particular generous I'd love to know what it's failing on, but I'm not that familiar with debugging on windows. Running it with a debugger should give a lot more information. If it helps, this is how I would debug on macOS:

v cmd/vsql
lldb cmd/vsql server -v test
> r

[michaeldesu]

I'm not at all familiar with the V debugging process, but I did some research and found this video which got me up and running, so I'll see how I go soon, but I guess it's better another with more experience do some investigation.

[michaeldesu]

Incidentally, it's worth to update your build instructions for Windows, e.g.

installation on Windows

v install elliotchance.vsql
v %USERPROFILE%\.vmodules\elliotchance\vsql\cmd\vsql.v

[elliotchance]

Since you're investigating I'll hold off updating the docs in case you find something that needs updating at the same time. With a bit of luck it might just be one little thing that's broken for windows users 👍