segmentation fault with example project from README #53

alex-dukhno · 2021-02-20T17:15:32Z

Hi thank you for this crate, I am considering to use it in my db project instead of sqlparser

However, when I tried to run simple project from README example:

use postgres_parser::*;

fn main() {
    let args: Vec<String> = std::env::args().collect();
    let query_string = args.get(1).expect("no arguments");
    let parse_list = match parse_query(query_string) {
        Ok(query) => query,
        Err(e) => {
            eprintln!("{:?}", e);
            std::process::exit(1);
        }
    };

    let as_json = serde_json::to_string_pretty(&parse_list).expect("failed to convert to json");
    println!("{}", as_json);
}

I got segmentation fault:

alex-dukhno@Alexs-MacBook Projects/test-pro (master %) » cargo run ../isomorphicdb/docs/user-guide/sql/basic_queries.sql
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/test-pro ../isomorphicdb/docs/user-guide/sql/basic_queries.sql`
[1]    45017 segmentation fault  cargo run ../isomorphicdb/docs/user-guide/sql/basic_queries.sql

however, when I run one example (e.g. scanner) it works 🤷‍♂️ :

alex-dukhno@Alexs-MacBook Projects/postgres-parser (fix-workflow-for-mac-os) » cargo run --example scanner ../isomorphicdb/docs/user-guide/sql/basic_queries.sql
   Compiling postgres-parser v0.2.2 (/Users/alex-dukhno/Projects/postgres-parser)
    Finished dev [unoptimized + debuginfo] target(s) in 15.26s
     Running `target/debug/examples/scanner ../isomorphicdb/docs/user-guide/sql/basic_queries.sql`
#1
-- Copyright 2020 - present Alex Dukhno
--
-- Licensed under the Apache License, Version 2.0 (the "License");
-- you may not use this file except in compliance with the License.
-- You may obtain a copy of the License at
--
--     http://www.apache.org/licenses/LICENSE-2.0
--
-- Unless required by applicable law or agreed to in writing, software
-- distributed under the License is distributed on an "AS IS" BASIS,
-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-- See the License for the specific language governing permissions and
-- limitations under the License.

create schema SMOKE_QUERIES;
-- {"CreateSchemaStmt":{"schemaname":"smoke_queries","if_not_exists":false}}
....

any advice on how to troubleshoot this appreciated 😄

The text was updated successfully, but these errors were encountered:

eeeebbbbrrrr · 2021-02-20T18:49:38Z

That's interesting. Can you post the contents of "basic_queries.sql"?

Also, can you run it via gdb/lldb to get a backtrace?

alex-dukhno · 2021-02-20T19:05:35Z

Can you post the contents of "basic_queries.sql"?

content of the file could be found here https://github.com/alex-dukhno/isomorphicdb/blob/main/docs/user-guide/sql/basic_queries.sql

Also, can you run it via gdb/lldb to get a backtrace?

let me set it up and try to run it

eeeebbbbrrrr · 2021-02-20T19:07:21Z

also, I suppose it's worth pointing out that that example is meant to be run as: cargo run "SQL STATEMENT HERE", not taking a path to a file.

That said, you should have just gotten a parse error, not a core dump

alex-dukhno · 2021-02-20T19:08:46Z

I configured https://github.com/japaric/rust-san#how-to-use-the-sanitizers
This is what I got when run project

alex-dukhno@Alexs-MacBook Projects/test-pro (master %) » RUSTFLAGS="-Z sanitizer=$SAN" cargo run --target x86_64-apple-darwin ../isomorphicdb/docs/user-guide/sql/basic_queries.sql
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/x86_64-apple-darwin/debug/test-pro ../isomorphicdb/docs/user-guide/sql/basic_queries.sql`
AddressSanitizer:DEADLYSIGNAL
=================================================================
==59457==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7fff2044b3ee bp 0x7ffeea67cbd0 sp 0x7ffeea67cba8 T0)
==59457==The signal is caused by a READ memory access.
==59457==Hint: this fault was caused by a dereference of a high value address (see register values below).  Dissassemble the provided pc to learn which register was used.
    #0 0x7fff2044b3ee in stack_not_16_byte_aligned_error+0x0 (libdyld.dylib:x86_64+0x143ee)
    #1 0x105aa9dab in raw_parser+0x3b (test-pro:x86_64+0x100529dab)
    #2 0x105a2a533 in postgres_parser::parser::parse_query::raw_parser_wrapper::h3445a9b124aa3ee1 parser.rs:119
    #3 0x105a28593 in postgres_parser::parser::parse_query::hdfbbb62e7b860e17 parser.rs:190
    #4 0x105708594 in test_pro::main::h67fdad59256500e9 main.rs:6
    #5 0x10570b29d in core::ops::function::FnOnce::call_once::he87eed73c0cb45c5 function.rs:227
    #6 0x10558d76e in std::sys_common::backtrace::__rust_begin_short_backtrace::hddb5b10bbc852178 backtrace.rs:125
    #7 0x1057147cf in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hf018630f157b2693 rt.rs:66
    #8 0x105b15923 in std::rt::lang_start_internal::h6cd9161d564e26bc rt.rs:51
    #9 0x10571472b in std::rt::lang_start::hc1b36c2fbbf96bb5 rt.rs:65
    #10 0x105708f31 in main+0x21 (test-pro:x86_64+0x100188f31)
    #11 0x7fff2044c620 in start+0x0 (libdyld.dylib:x86_64+0x15620)

==59457==Register values:
rax = 0x0000000000005e38  rbx = 0x00007ffeea67cee0  rcx = 0x00007ffeea67cbe8  rdx = 0x0000000000000000
rdi = 0x0000625000005218  rsi = 0x0000000000000400  rbp = 0x00007ffeea67cbd0  rsp = 0x00007ffeea67cba8
 r8 = 0x0000000000000020   r9 = 0x0000000000000001  r10 = 0x00000001107ee450  r11 = 0x0000000105c804b0
r12 = 0x00007ffeea67d480  r13 = 0x00007ffeea67d4a0  r14 = 0xf3f3f3f8f8f8f8f8  r15 = 0xf2f2f2f8f8f8f2f2
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libdyld.dylib:x86_64+0x143ee) in stack_not_16_byte_aligned_error+0x0
==59457==ABORTING
[1]    59457 abort      RUSTFLAGS="-Z sanitizer=$SAN" cargo run --target x86_64-apple-darwin

eeeebbbbrrrr · 2021-02-20T19:11:28Z

That’s helpful. Thanks. It crashed in Postgres’ code which means I’ve got a bug somewhere on the rust side (likely). I’ll investigate.

But like I said above, you’re using that example wrong. :)

alex-dukhno · 2021-02-20T19:13:13Z

But like I said above, you’re using that example wrong. :)

Give me a minute 😄
This is with cargo run "SQL STATEMENT HERE" example

alex-dukhno@Alexs-MacBook Projects/test-pro (master %) » RUSTFLAGS="-Z sanitizer=$SAN" cargo run --target x86_64-apple-darwin "create schema schema_name"
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/x86_64-apple-darwin/debug/test-pro 'create schema schema_name'`
'"create schema schema_name"'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==59737==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7fff2044b3ee bp 0x7ffee9174af0 sp 0x7ffee9174ac8 T0)
==59737==The signal is caused by a READ memory access.
==59737==Hint: this fault was caused by a dereference of a high value address (see register values below).  Dissassemble the provided pc to learn which register was used.
    #0 0x7fff2044b3ee in stack_not_16_byte_aligned_error+0x0 (libdyld.dylib:x86_64+0x143ee)
    #1 0x106fb1d5b in raw_parser+0x3b (test-pro:x86_64+0x100529d5b)
    #2 0x106f324e3 in postgres_parser::parser::parse_query::raw_parser_wrapper::h3445a9b124aa3ee1 parser.rs:119
    #3 0x106f30543 in postgres_parser::parser::parse_query::hdfbbb62e7b860e17 parser.rs:190
    #4 0x106c10568 in test_pro::main::h67fdad59256500e9 main.rs:7
    #5 0x106c1324d in core::ops::function::FnOnce::call_once::he87eed73c0cb45c5 function.rs:227
    #6 0x106a954be in std::sys_common::backtrace::__rust_begin_short_backtrace::hddb5b10bbc852178 backtrace.rs:125
    #7 0x106c1c77f in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hf018630f157b2693 rt.rs:66
    #8 0x10701d8d3 in std::rt::lang_start_internal::h6cd9161d564e26bc rt.rs:51
    #9 0x106c1c6db in std::rt::lang_start::hc1b36c2fbbf96bb5 rt.rs:65
    #10 0x106c10ee1 in main+0x21 (test-pro:x86_64+0x100188ee1)
    #11 0x7fff2044c620 in start+0x0 (libdyld.dylib:x86_64+0x15620)

==59737==Register values:
rax = 0x0000000000005e38  rbx = 0x00007ffee9174e00  rcx = 0x00007ffee9174b08  rdx = 0x0000000000000000
rdi = 0x0000625000005218  rsi = 0x0000000000000400  rbp = 0x00007ffee9174af0  rsp = 0x00007ffee9174ac8
 r8 = 0x0000000000000007   r9 = 0xffffe3b5fffff5c4  r10 = 0x000000010baeb450  r11 = 0x00000001071884b0
r12 = 0x00007ffee91753a0  r13 = 0x00007ffee91753c0  r14 = 0xf3f3f3f8f8f8f8f8  r15 = 0xf2f2f2f8f8f8f2f2
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libdyld.dylib:x86_64+0x143ee) in stack_not_16_byte_aligned_error+0x0
==59737==ABORTING
[1]    59737 abort      RUSTFLAGS="-Z sanitizer=$SAN" cargo run --target x86_64-apple-darwin

eeeebbbbrrrr · 2021-02-20T19:18:04Z

What kind of MacBook do you have? Is it a new M1?

alex-dukhno · 2021-02-20T19:21:10Z

alex-dukhno@Alexs-MacBook Projects/test-pro (master %) » /Volumes/Macintosh\ HD/usr/sbin/system_profiler SPHardwareDataType
Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro16,1
      Processor Name: 8-Core Intel Core i9
      Processor Speed: 2,3 GHz
      Number of Processors: 1
      Total Number of Cores: 8
      L2 Cache (per Core): 256 KB
      L3 Cache: 16 MB
      Hyper-Threading Technology: Enabled
      Memory: 16 GB
      System Firmware Version: 1554.80.3.0.0 (iBridge: 18.16.14346.0.0,0)
      Serial Number (system): C02DX15EMD6Q
      Hardware UUID: 13B60DC7-4A06-5A78-8A14-B5673CC5331D
      Provisioning UDID: 13B60DC7-4A06-5A78-8A14-B5673CC5331D
      Activation Lock Status: Enabled

eeeebbbbrrrr · 2021-02-20T19:23:29Z

So the "scanner" example works fine, but the basic example that simply calls the parse_query() function crashes. Weird. Ultimately, that's what the scanner example does too.

I can't re-create this locally on my MacBook. Still looking...

eeeebbbbrrrr · 2021-02-20T19:43:24Z

what version of Rust are you using? I'm kinda stumped at the moment. There's gotta be some difference between our environments.

alex-dukhno · 2021-02-20T19:44:51Z

what version of Rust are you using? I'm kinda stumped at the moment. There's gotta be some difference between our environments.

rustc -V                                                                                                                                                                                (main)isomorphicdb
rustc 1.50.0 (cb75ad5db 2021-02-10)

Ok, so I run the following experiment.

I copied the scanner example into my project and run it - it fails with sigfault.
I copied my project code instead of scanner code it worked out ...

I suppose the difference somewhere in project configuration ...

eeeebbbbrrrr · 2021-02-20T19:45:44Z

can you tar up your example project that fails and post it here? or email it to me: eebbrr @ gmail dot com

eeeebbbbrrrr · 2021-02-20T19:48:06Z

I was on rustc 1.49.0 (e1884a8e3 2020-12-29) -- just upgraded to 1.50.0 and am rebuilding everything.

alex-dukhno · 2021-02-20T19:50:39Z

test-pro.tar.gz

eeeebbbbrrrr · 2021-02-20T19:58:29Z

Your project works for me:

 cargo run
    Updating crates.io index
  Downloaded libloading v0.7.0
  Downloaded clang-sys v1.1.1
  Downloaded 2 crates (62.8 KB) in 0.61s
...
   Compiling test-pro v0.1.0 (/Users/e_ridge/Downloads/test-pro)
warning: unused variable: `i`
 --> src/main.rs:7:10
  |
7 |     for (i, stmt) in scanner.into_iter().enumerate() {
  |          ^ help: if this is intentional, prefix it with an underscore: `_i`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 49.84s
     Running `target/debug/test-pro`
true
{
  "SelectStmt": {
    "targetList": [
      {
        "ResTarget": {
          "val": {
            "A_Const": {
              "val": {
                "int": 1
              }
            }
          }
        }
      }
    ],
    "limitOption": "LIMIT_OPTION_COUNT",
    "op": "SETOP_NONE",
    "all": false
  }
}

eeeebbbbrrrr · 2021-02-20T19:58:52Z

(oh, and this is with rustc 1.50.0 (cb75ad5db 2021-02-10))

alex-dukhno · 2021-02-20T19:58:59Z

This fixes the sigfault in my project

diff --git Cargo.toml Cargo.toml
index 5eed888..61b715c 100644
--- Cargo.toml
+++ Cargo.toml
@@ -5,6 +5,6 @@ authors = ["Alex Dukhno <alex.dukhno@icloud.com>"]
 edition = "2018"

 [dependencies]
-postgres-parser = "0.2"
+postgres-parser = { path = "../postgres-parser" }
 serde = { version = "1.0.123", features = ["derive"] }
 serde_json = "1.0.62"

Is this possible because building parser locally is different from building and compiling it from crates.io? is it because of build.rs ?

eeeebbbbrrrr · 2021-02-20T20:00:26Z

wel, that's interesting. I used it from crates.io too. And my private project that uses it builds it from crates.io w/o any problems.

What does cargo tree say? The published version is 0.2.1 -- is that what you have from crates.io?

alex-dukhno · 2021-02-20T20:06:09Z

cargo tree                                                                                                                                                                                     134 ↵
test-pro v0.1.0 (/Users/alex-dukhno/Projects/test-pro)
├── postgres-parser v0.2.1
│   ├── lazy_static v1.4.0
│   └── serde v1.0.123
│       └── serde_derive v1.0.123 (proc-macro)
│           ├── proc-macro2 v1.0.24
│           │   └── unicode-xid v0.2.1
│           ├── quote v1.0.9
│           │   └── proc-macro2 v1.0.24 (*)
│           └── syn v1.0.60
│               ├── proc-macro2 v1.0.24 (*)
│               ├── quote v1.0.9 (*)
│               └── unicode-xid v0.2.1
│   [build-dependencies]
│   ├── bindgen v0.57.0
│   │   ├── bitflags v1.2.1
│   │   ├── cexpr v0.4.0
│   │   │   └── nom v5.1.2
│   │   │       └── memchr v2.3.4
│   │   │       [build-dependencies]
│   │   │       └── version_check v0.9.2
│   │   ├── clang-sys v1.1.1
│   │   │   ├── glob v0.3.0
│   │   │   ├── libc v0.2.86
│   │   │   └── libloading v0.7.0
│   │   │       └── cfg-if v1.0.0
│   │   │   [build-dependencies]
│   │   │   └── glob v0.3.0
│   │   ├── clap v2.33.3
│   │   │   ├── ansi_term v0.11.0
│   │   │   ├── atty v0.2.14
│   │   │   │   └── libc v0.2.86
│   │   │   ├── bitflags v1.2.1
│   │   │   ├── strsim v0.8.0
│   │   │   ├── textwrap v0.11.0
│   │   │   │   └── unicode-width v0.1.8
│   │   │   ├── unicode-width v0.1.8
│   │   │   └── vec_map v0.8.2
│   │   ├── env_logger v0.8.3
│   │   │   ├── atty v0.2.14 (*)
│   │   │   ├── humantime v2.1.0
│   │   │   ├── log v0.4.14
│   │   │   │   └── cfg-if v1.0.0
│   │   │   ├── regex v1.4.3
│   │   │   │   ├── aho-corasick v0.7.15
│   │   │   │   │   └── memchr v2.3.4
│   │   │   │   ├── memchr v2.3.4
│   │   │   │   ├── regex-syntax v0.6.22
│   │   │   │   └── thread_local v1.1.3
│   │   │   │       └── once_cell v1.5.2
│   │   │   └── termcolor v1.1.2
│   │   ├── lazy_static v1.4.0
│   │   ├── lazycell v1.3.0
│   │   ├── log v0.4.14 (*)
│   │   ├── peeking_take_while v0.1.2
│   │   ├── proc-macro2 v1.0.24 (*)
│   │   ├── quote v1.0.9 (*)
│   │   ├── regex v1.4.3 (*)
│   │   ├── rustc-hash v1.1.0
│   │   ├── shlex v0.1.1
│   │   └── which v3.1.1
│   │       └── libc v0.2.86
│   ├── num_cpus v1.13.0
│   │   └── libc v0.2.86
│   ├── proc-macro2 v1.0.24 (*)
│   ├── quote v1.0.9 (*)
│   └── syn v1.0.60 (*)
├── serde v1.0.123 (*)
└── serde_json v1.0.62
    ├── itoa v0.4.7
    ├── ryu v1.0.5
    └── serde v1.0.123 (*)

Weird question, maybe because it is night here 🤦 , I have postgres installed locally could it cause some problem?

eeeebbbbrrrr · 2021-02-20T20:10:06Z

I have postgres installed locally could it cause some problem?

Naw. I do too -- 6 different versions!

postgres-parser downloads it, configures, and compiles it, via build.rs, all in the "target" directory. Which for a crates.io downloaded package is in its ~/.cargo/registry directory.

I've just removed my ~/.cargo/registry directory and am trying to build/run your test project again. I'm really stumped.

eeeebbbbrrrr · 2021-02-20T20:13:31Z

I've just removed my ~/.cargo/registry directory and am trying to build/run your test project again. I'm really stumped.

Yeah, that worked fine too. I'm clueless at the moment. 😢

alex-dukhno · 2021-02-20T20:23:00Z

Ok, I will debug it with lldb tomorrow. I hope I get something useful. Thanks for the help

eeeebbbbrrrr · 2021-02-20T20:26:21Z

May you can try removing your ~/.cargo/registry directory, doing a cargo clean, and see what happens?

This is definitely weird.

What version of clang do you have? Mine is:

clang version 10.0.0 
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin

Which apparently I must have installed via brew.

alex-dukhno · 2021-02-20T20:30:01Z

May you can try removing your ~/.cargo/registry directory, doing a cargo clean, and see what happens?

I did and got the same

alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) » rm -rf ~/.cargo/registry
alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) » cargo run
...
warning: unused variable: `i`
 --> src/main.rs:7:10
  |
7 |     for (i, stmt) in scanner.into_iter().enumerate() {
  |          ^ help: if this is intentional, prefix it with an underscore: `_i`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 49.71s
     Running `target/debug/test-pro`
true
[1]    65718 segmentation fault  cargo run

What version of clang do you have? Mine is:
clang version 10.0.0 
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
Which apparently I must have installed via brew.

I've installed llvm today via brew

alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) » clang -v                                                                                                                                                                                      139 ↵
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

eeeebbbbrrrr · 2021-02-20T20:31:20Z

well, actually, that's the clang installed by XCode.

I wonder if that's a thing... There's a "known issue" with that, and I wonder if that's what we're seeing: https://github.com/zombodb/postgres-parser#known-issues

alex-dukhno · 2021-02-20T20:42:13Z

Then I am wondering why example works fine? How is it possible that in directly cloned repo another clang is used?

eeeebbbbrrrr · 2021-02-20T20:43:24Z

Yeah. I’m wondering that too. I dunno. Soooo weird.

eeeebbbbrrrr · 2021-02-20T20:46:36Z

I wonder if it has something to do with postgres-parser's published Cargo.lock file. It appears to be a little out of date:

diff --git a/Cargo.lock b/Cargo.lock
index 3a93997..e8886be 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -75,9 +75,9 @@ checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
 
 [[package]]
 name = "clang-sys"
-version = "1.0.3"
+version = "1.1.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "0659001ab56b791be01d4b729c44376edc6718cf389a502e579b77b758f3296c"
+checksum = "f54d78e30b388d4815220c8dd03fea5656b6c6d32adb59e89061552a102f8da1"
 dependencies = [
  "glob",
  "libc",
@@ -101,9 +101,9 @@ dependencies = [
 
 [[package]]
 name = "env_logger"
-version = "0.8.2"
+version = "0.8.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "f26ecb66b4bdca6c1409b40fb255eefc2bd4f6d135dab3c3124f80ffa2a9661e"
+checksum = "17392a012ea30ef05a610aa97dfb49496e71c9f676b27879922ea5bdf60d9d3f"
 dependencies = [
  "atty",
  "humantime",
@@ -159,9 +159,9 @@ checksum = "b7282d924be3275cec7f6756ff4121987bc6481325397dde6ba3e7802b1a8b1c"
 
 [[package]]
 name = "libloading"
-version = "0.6.7"
+version = "0.7.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "351a32417a12d5f7e82c368a66781e307834dae04c6ce0cd4456d52989229883"
+checksum = "6f84d96438c15fcd6c3f244c8fce01d1e2b9c6b5623e9c711dc9286d8fc92d6a"
 dependencies = [
  "cfg-if",
  "winapi",
@@ -239,9 +239,9 @@ dependencies = [
 
 [[package]]
 name = "quote"
-version = "1.0.8"
+version = "1.0.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "991431c3519a3f36861882da93630ce66b52918dcf1b8e2fd66b397fc96f28df"
+checksum = "c3d0b9745dc2debf507c8422de05d7226cc1f0644216dfdfead988f9b1ab32a7"
 dependencies = [
  "proc-macro2",
 ]

eeeebbbbrrrr · 2021-02-20T20:47:10Z

let me update all the dependencies and Cargo.lock and publish v0.2.3 and lets see what happens.

alex-dukhno · 2021-02-20T20:52:53Z

alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) »source ~/.zshenv
alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) »clang -v
clang version 11.1.0
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) » cargo clean
alex-dukhno@Alexs-MacBook Downloads/test-pro (master %) » cargo run

and it works ...

warning: unused variable: `i`
 --> src/main.rs:7:10
  |
7 |     for (i, stmt) in scanner.into_iter().enumerate() {
  |          ^ help: if this is intentional, prefix it with an underscore: `_i`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 3m 18s
     Running `target/debug/test-pro`
true
{
  "SelectStmt": {
    "targetList": [
      {
        "ResTarget": {
          "val": {
            "A_Const": {
              "val": {
                "int": 1
              }
            }
          }
        }
      }
    ],
    "limitOption": "LIMIT_OPTION_COUNT",
    "op": "SETOP_NONE",
    "all": false
  }
}

eeeebbbbrrrr · 2021-02-20T20:54:55Z

hmm. So it has something to do with Apple's clang/llvm toolchain. That's cool. :(

I've just published v0.2.3 with updated deps and Cargo.lock. You'll need to do a cargo update to pick it up.

eeeebbbbrrrr · 2021-02-20T20:57:02Z

I've uninstalled brew's llvm and am trying from scratch with Apple's. If I can reproduce it here then I can probably debug it.

eeeebbbbrrrr · 2021-02-20T21:15:47Z

Okay, so postgres-parser won't build at all without llvm being installed by brew. It requires a number of specific llvm utilities like llvm-ar, llvm-link, llvm-lto, opt.

And I think with that, the brew-installed clang binary needs to be on the path too. Perhaps the problem all along here is that your environment was mix/matching some bit of brew-installed llvm and Apple's clang?

alex-dukhno · 2021-02-21T08:33:48Z

And I think with that, the brew-installed clang binary needs to be on the path too. Perhaps the problem all along here is that your environment was mix/matching some bit of brew-installed llvm and Apple's clang?

That is the most possible explanation.

The only thing is that I can't explain is that if building parser requires llvm-ar, llvm-link, llvm-lto, opt and they are in "$(brew --prefix llvm)/bin" folder along with llvm clang.
For some reason OS used Apple clang until I reset PATH once again

EDIT
putting export PATH="/usr/local/opt/llvm/bin:$PATH" into ~/.zshrc instead of ~/.zshenv helps to fix problem with clang

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

segmentation fault with example project from README #53

segmentation fault with example project from README #53

alex-dukhno commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 21, 2021 •

edited

segmentation fault with example project from README #53

segmentation fault with example project from README #53

Comments

alex-dukhno commented Feb 20, 2021 • edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 • edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 • edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021 • edited

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021 • edited

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

eeeebbbbrrrr commented Feb 20, 2021

alex-dukhno commented Feb 21, 2021 • edited

alex-dukhno commented Feb 20, 2021 •

edited

alex-dukhno commented Feb 20, 2021 •

edited

alex-dukhno commented Feb 20, 2021 •

edited

alex-dukhno commented Feb 20, 2021 •

edited

eeeebbbbrrrr commented Feb 20, 2021 •

edited

alex-dukhno commented Feb 21, 2021 •

edited