profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/NotSqrt/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

django-parler/django-parler 502

Easily translate "cheese omelet" into "omelette au fromage".

NotSqrt/django-bootstrap3 1

Bootstrap 3 integration with Django.

NotSqrt/aiohttp 0

HTTP client/server framework for asyncio

NotSqrt/binder 0

Django Web Admin Gui for manging BIND DNS Zones

NotSqrt/celery 0

Distributed Task Queue (development branch)

NotSqrt/covid-19 0

How does COVID-19 spread around the world? Charts, data, dashboards and interpretations...

NotSqrt/dennis 0

dennis is a series of localization tools

NotSqrt/Diamond 0

Diamond is a python daemon that collects system metrics and publishes them to Graphite (and others). It is capable of collecting cpu, memory, network, i/o, load and disk metrics. Additionally, it features an API for implementing custom collectors for gathering metrics from almost any source.

NotSqrt/distributed 0

Distributed computation in Python

NotSqrt/django 0

The Web framework for perfectionists with deadlines.

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

I'm still a little puzzled by the fact that it's possible to cross-compile entire projects between platforms (eg. from x86 to arm), but it seems much harder to compile for a target-cpu that has more features (eg AVX512) on the same platform, because the build.rs scripts are built with the target flags, not the host flags ..

leet4tari

comment created time in 4 days

issue openedmbi/django-rosetta

'Last-Translator' is written as b'....' in pofile

Hello,

(Using python3.6, django 1.11, latest polib, django-rosetta==0.9.4)

There's a .encode('ascii', 'ignore') that is used when preparing the value for Last-Translator here: https://github.com/mbi/django-rosetta/blob/417094f0f19de1e392adf9ea1a7471d5914d8c3c/rosetta/views.py#L378

Which makes the translator appear as follows in my po files:

"Last-Translator: b'FirstName LastName <email@domain.ltd>'\n"

I guess that now that you only support python3, this string should be a str and not bytes.

Thanks !

created time in 9 days

startedtensorbase/tensorbase

started time in 17 days

issue openedawestlake87/pyo3-asyncio

Tokio runtime: native protection against forking ?

Hello,

This is an enhancement proposal, to help others in the same situation : a combination of initializing a tokio runtime via init_multi_thread_once or similar calls, and forking of the python process (when spawning celery workers, or possibly web workers, etc.).

If the tokio runtime is initialized in a first process, then forking occurs, then you try to use the runtime in the forked process, it hangs forever in async tasks, even with timeouts.

A possible protection to save debugging time in the development of pyo3 modules with long running tokio runtime is to save the current value of std::process::id() when creating the runtime, and then checking that it hasn't change when calling get_runtime().

What do you think of that ? I have worked with tokio only, so I can't say whether there's a similar problem for other runtimes or not. Thanks !

created time in 19 days

issue closedsfackler/rust-postgres

Connection is stuck in tokio_postgres::connect, despite timeout

Hello,

I'm having troubles with a connection to a database on localhost. My setup is not very simple : a PyO3 library, that starts a tokio runtime at the first import from python, and then a connection is opened when calling some functions from python. When working from a basic python process, it works correctly. When working inside a celery worker (that uses forking), it fails.

I've confirmed that the connect_with_timeout function is called with a usable timeout, but the TcpStream::connect call never ends despite the time::timeout wrapper.

With wireshark, I have confirmed that the handshake of the TCP connection is done, but then no data is exchanged, and from the point of view of postgres, no connection is attempted.

The tracing crate with the RUSTFLAGS="--cfg tokio_unstable" compilation flag does not give more details.

I'm using latest rust, tokio, tokio-postgres versions, on ubuntu.

Do you have any tips on where to go from here to continue the debugging ? Does that remind you of a similar problem ?

Thanks a lot !

closed time in 23 days

NotSqrt

issue commentsfackler/rust-postgres

Connection is stuck in tokio_postgres::connect, despite timeout

Indeed !

I moved the tokio runtime initialisation at first usage instead of first import from python, and the issue is gone. It certainly was due to celery forking a process where a tokio runtime was already initialized.

Problem solved !

NotSqrt

comment created time in 23 days

issue openedsfackler/rust-postgres

Connection is stuck in tokio_postgres::connect, despite timeout

Hello,

I'm having troubles with a connection to a database on localhost. My setup is not very simple : a PyO3 library, that starts a tokio runtime at the first import from python, and then a connection is opened when calling some functions from python. When working from a basic python process, it works correctly. When working inside a celery worker (that uses forking), it fails.

I've confirmed that the connect_with_timeout function is called with a usable timeout, but the TcpStream::connect call never ends despite the time::timeout wrapper.

With wireshark, I have confirmed that the handshake of the TCP connection is done, but then no data is exchanged, and from the point of view of postgres, no connection is attempted.

The tracing crate with the RUSTFLAGS="--cfg tokio_unstable" compilation flag does not give more details.

I'm using latest rust, tokio, tokio-postgres versions, on ubuntu.

Do you have any tips on where to go from here to continue the debugging ? Does that remind you of a similar problem ?

Thanks a lot !

created time in 23 days

startedbenfred/py-spy

started time in a month

startedLANDrop/LANDrop

started time in a month

startedfabacab/awesome-cybersecurity-blueteam

started time in a month

startedhealthchecks/healthchecks

started time in a month

startedleeoniya/uPlot

started time in a month

startedsurban/blez

started time in 2 months

startedbrendangregg/perf-tools

started time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

And at opt-level = 1, it's yet another illegal instruction:

Program received signal SIGILL, Illegal instruction.

0x0000555555564118 in core::alloc::layout::Layout::padding_needed_for (self=<optimized out>, align=1) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/alloc/layout.rs:253
253             let len_rounded_up = len.wrapping_add(align).wrapping_sub(1) & !align.wrapping_sub(1);
(gdb) bt
#0  0x0000555555564118 in core::alloc::layout::Layout::padding_needed_for (self=<optimized out>, align=1) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/alloc/layout.rs:253
#1  0x00005555555642b3 in core::alloc::layout::Layout::repeat (self=0x7fffffffd048, n=8192) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/alloc/layout.rs:290
#2  0x00005555555641ce in core::alloc::layout::Layout::array (n=8192) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/alloc/layout.rs:394
#3  0x00005555555648e4 in alloc::raw_vec::RawVec<T,A>::allocate_in (capacity=1, init=alloc::raw_vec::AllocInit::Uninitialized, alloc=...)
    at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/raw_vec.rs:192
#4  0x0000555555566c7d in alloc::raw_vec::RawVec<T,A>::with_capacity_in (capacity=8192, alloc=...) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/raw_vec.rs:142
#5  0x0000555555566b29 in alloc::vec::Vec<T,A>::with_capacity_in (capacity=8192, alloc=...) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:572
#6  0x0000555555566b19 in alloc::vec::Vec<T>::with_capacity (capacity=8192) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:438
#7  0x00005555555666e5 in std::io::buffered::bufwriter::BufWriter<W>::with_capacity (capacity=8192, inner=0x7fffffffd184)
    at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/buffered/bufwriter.rs:110
#8  0x0000555555566719 in std::io::buffered::bufwriter::BufWriter<W>::new (inner=0x1) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/buffered/bufwriter.rs:92
#9  0x000055555555eb6c in build_script_main::tests::build_tests () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/tests.rs:250
#10 0x00005555555664e5 in build_script_main::main () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs:181
leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

Actual error:

OUT_DIR=/tmp RUST_BACKTRACE=full gdb target/release/build/typenum-0333481abf8719b3/build-script-main:

Program received signal SIGILL, Illegal instruction.
build_script_main::tests::build_tests () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/tests.rs:267
267             write!(writer, "{}", uint_binary_test(a, "Shl", b, a << b))?;
(gdb) bt
#0  build_script_main::tests::build_tests () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/tests.rs:267
#1  0x0000555555561d20 in build_script_main::main () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs:181
leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

Progress !! but new panic when I add this to my cargo.toml.

[profile.release.build-override]
opt-level = 3

RUST_BACKTRACE=full gdb target/release/build/typenum-0333481abf8719b3/build-script-main:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotPresent', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs:89:39
stack backtrace:
   0:     0x555555579650 - std::backtrace_rs::backtrace::libunwind::trace::h63b7a90188ab5fb3
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x555555579650 - std::backtrace_rs::backtrace::trace_unsynchronized::h80aefbf9b851eca7
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x555555579650 - std::sys_common::backtrace::_print_fmt::hbef05ae4237a4d72
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x555555579650 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h28abce2fdb9884c2
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x55555559011f - core::fmt::write::h3b84512577ca38a8
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/fmt/mod.rs:1092:17
   5:     0x555555577b62 - std::io::Write::write_fmt::h465f8feea02e2aa1
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/io/mod.rs:1572:15
   6:     0x55555557b2f5 - std::sys_common::backtrace::_print::h525280ee0d29bdde
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x55555557b2f5 - std::sys_common::backtrace::print::h1f0f5b9f3ef8fb78
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x55555557b2f5 - std::panicking::default_hook::{{closure}}::ha5838f6faa4a5a8f
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:208:50
   9:     0x55555557ada3 - std::panicking::default_hook::hfb9fe98acb0dcb3b
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:225:9
  10:     0x55555557b8fd - std::panicking::rust_panic_with_hook::hb89f5f19036e6af8
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:591:17
  11:     0x55555557b497 - std::panicking::begin_panic_handler::{{closure}}::h119e7951427f41da
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:497:13
  12:     0x555555579b0c - std::sys_common::backtrace::__rust_end_short_backtrace::hce386c44bf47a128
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x55555557b3f9 - rust_begin_unwind
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
  14:     0x55555555c2f1 - core::panicking::panic_fmt::h2242888e8769cd33
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
  15:     0x55555555c1e3 - core::option::expect_none_failed::hb1edf11f73e63728
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/option.rs:1329:5
  16:     0x555555561e35 - core::result::Result<T,E>::unwrap::h229fbcf442e5a18a
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1037:23
  17:     0x555555561e35 - build_script_main::main::h479b4ed7c1a3c23d
                               at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs:89:19
  18:     0x555555560a33 - core::ops::function::FnOnce::call_once::h0c8379743e5cd6ea
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  19:     0x555555560a33 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5999824a98921ca0
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:125:18
  20:     0x555555560a09 - std::rt::lang_start::{{closure}}::h3e2e1f3ebac18c0e
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:66:18
  21:     0x55555557bcfa - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h44574effd2120c86
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/ops/function.rs:259:13
  22:     0x55555557bcfa - std::panicking::try::do_call::h10b0bd4879c8dfb0
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:379:40
  23:     0x55555557bcfa - std::panicking::try::h60c6780d33419e92
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:343:19
  24:     0x55555557bcfa - std::panic::catch_unwind::h111f33e08c52e2ce
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panic.rs:431:14
  25:     0x55555557bcfa - std::rt::lang_start_internal::h126f2e09345dbfda
                               at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/rt.rs:51:25
  26:     0x5555555620a8 - main
  27:     0x7ffff6e22bf7 - __libc_start_main
  28:     0x55555555c95a - _start
  29:                0x0 - <unknown>
leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

Found the issue !

With this simple hello_wolrd:

fn main() {
    let highest: u64 = 1024;
    let first2: u32 = (highest as f64).log(2.0).round() as u32 + 1; 
    println!("{}", first2);
}

RUSTFLAGS="-C target-cpu=broadwell" cargo run --release works. But RUSTFLAGS="-C target-cpu=broadwell" cargo run fails.

The issue is the opt-level. at opt-level > 0, the round seems to be eliminated. But at opt-level = 0 (which is certainly the level that is used for the build/main.rs script), there is a small difference in asm for the hello_world:

(files generated with RUSTFLAGS="--emit asm -C target-cpu=broadwell" cargo run and RUSTFLAGS="--emit asm -C target-cpu=ivybridge" cargo run respectively)

diff -C5 hello_round_broadwell.s hello_round_ivybridge.s 
*** hello_round_broadwell.s     2021-05-21 14:26:24.617976214 +0200
--- hello_round_ivybridge.s     2021-05-21 14:31:24.847106617 +0200
***************
*** 323,333 ****
  .Ltmp22:
        .loc    3 87 18 prologue_end
        vmovaps %xmm0, %xmm1
        vmovdqa .LCPI7_0(%rip), %xmm2
        vpand   %xmm2, %xmm1, %xmm2
!       vpbroadcastq    .LCPI7_1(%rip), %xmm1
        vpor    %xmm2, %xmm1, %xmm1
        vaddsd  %xmm1, %xmm0, %xmm1
        vroundsd        $11, %xmm1, %xmm0, %xmm0
        vmovsd  %xmm0, 16(%rsp)
        vmovsd  16(%rsp), %xmm0
--- 323,333 ----
  .Ltmp22:
        .loc    3 87 18 prologue_end
        vmovaps %xmm0, %xmm1
        vmovdqa .LCPI7_0(%rip), %xmm2
        vpand   %xmm2, %xmm1, %xmm2
!       vmovddup        .LCPI7_1(%rip), %xmm1
        vpor    %xmm2, %xmm1, %xmm1
        vaddsd  %xmm1, %xmm0, %xmm1
        vroundsd        $11, %xmm1, %xmm0, %xmm0
        vmovsd  %xmm0, 16(%rsp)
        vmovsd  16(%rsp), %xmm0

So potentially, using opt-level other than 0 for your build/main.rs might solve this issue ! No idea if that's possible !

leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

intrinsics::roundf64 seems to point to llvm.round.f64 in codegen, so I assume that it is in LLVM that build-script-main is made to use a round that is specialized for AVX2 or similar, that is not available on ivybridge.

leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

Here is an excerpt of the build log:


cargo rustc --lib --manifest-path Cargo.toml --features pyo3/extension-module --release --verbose -- --crate-type cdylib --cfg=Py_3
   Compiling typenum v1.13.0
     Running `rustc --crate-name build_script_main --edition=2018 /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off -C metadata=de78301006a8644b -C extra-filename=-de78301006a8644b --out-dir /home/user/project/target/release/build/typenum-de78301006a8644b -L dependency=/home/user/project/target/release/deps --cap-lints allow -C target-cpu=broadwell`
     Running `/home/user/project/target/release/build/typenum-de78301006a8644b/build-script-main`
error: failed to run custom build command for `typenum v1.13.0`

Caused by:
  process didn't exit successfully: `/home/user/project/target/release/build/typenum-de78301006a8644b/build-script-main` (signal: 4, SIGILL: illegal instruction)
warning: build failed, waiting for other jobs to finish...
error: build failed
error: cargo failed with code: 101

Running gdb /home/user/project/target/release/build/typenum-de78301006a8644b/build-script-main gives:

Program received signal SIGILL, Illegal instruction.
0x000055555556997a in std::f64::<impl f64>::round (self=10) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/f64.rs:87
87              unsafe { intrinsics::roundf64(self) }

(gdb) bt
#0  0x000055555556997a in std::f64::<impl f64>::round (self=10) at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/f64.rs:87
#1  0x000055555556a616 in build_script_main::main () at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.13.0/build/main.rs:83

This is with rustc 1.52.1.

leet4tari

comment created time in 2 months

issue commentpaholg/typenum

Compile fails with target_cpu on GitHub Actions for OSX - illegal instruction

Follow-up question !

Is it expected to receive SIGILL: illegal instruction when cross-building typenum with -C target-cpu=broadwell from another type of CPU (ivybridge in this case) ?

Thanks !

leet4tari

comment created time in 2 months

fork NotSqrt/covid-19

How does COVID-19 spread around the world? Charts, data, dashboards and interpretations...

fork in 2 months

startedasottile/pyupgrade

started time in 2 months