signal 11: segmentation fault when have field on struct #19652

axpira · 2023-10-25T12:21:34Z

Describe the bug

module main

import vweb

fn main() {
	println('Hello World!')
	r := Repository.new()
	Middleware.start(r)!
}

struct Repository {
	url string
}

fn Repository.new() Repository {
	return Repository{}
}

fn (r Repository) ping() {
	println('pong')
}

interface Pinger {
	ping()
}

struct Middleware {
	vweb.Context
	pinger Pinger
}

fn Middleware.start(pinger Pinger) ! {
	mut m := &Middleware{
		pinger: pinger
	}
	vweb.run_at(m, vweb.RunParams{
		port: 8080
	})!
}

fn (mut m Middleware) hello() vweb.Result {
	m.pinger.ping()
	return m.text('Hello')
}

Reproduction Steps

On my machine when I call:

curl http://localhost:8080/hello

Then I receive:

Hello World!
[Vweb] Running app on http://localhost:8080/
[Vweb] We have 7 workers
signal 11: segmentation fault
0   libsystem_platform.dylib            0x000000019bf76a24 _sigtramp + 56
1   tbot                                0x000000010427b160 main__Middleware_hello + 48
2   tbot                                0x000000010427b160 main__Middleware_hello + 48
3   tbot                                0x00000001042796b0 vweb__handle_route_T_main__Middleware + 2524
4   tbot                                0x0000000104278c24 vweb__handle_conn_T_main__Middleware + 2844
5   tbot                                0x000000010427cc50 vweb__Worker_T_main__Middleware_process_incoming_requests_T_main__Middleware + 272
6   tbot                                0x00000001041f7cc8 vweb__Worker_T_main__Middleware_process_incoming_requests_T_main__Middleware_thread_wrapper + 36
7   tbot                                0x0000000104290d60 GC_pthread_start + 104
8   libsystem_pthread.dylib             0x000000019bf47fa8 _pthread_start + 148
9   libsystem_pthread.dylib             0x000000019bf42da0 thread_start + 8

Expected Behavior

Success.

In struct Repository:

struct Repository {
	url string
}

If I remove field url then doesn't have any error

Current Behavior

Output:

V panic: malloc_noscan(78) failed
v hash: 0b0499b
/tmp/v_1000/v2.3929247846798868269.tmp.c:20737: at _v_panic: Backtrace
/tmp/v_1000/v2.3929247846798868269.tmp.c:20998: by malloc_noscan
/tmp/v_1000/v2.3929247846798868269.tmp.c:21148: by memdup_noscan
/tmp/v_1000/v2.3929247846798868269.tmp.c:16409: by strings__Builder_str
/tmp/v_1000/v2.3929247846798868269.tmp.c:25937: by str_intp
/tmp/v_1000/v2.3929247846798868269.tmp.c:36930: by v__vcache__CacheManager_mod_postfix_with_key2cpath
/tmp/v_1000/v2.3929247846798868269.tmp.c:46031: by v__builder__Builder_get_os_cflags
/tmp/v_1000/v2.3929247846798868269.tmp.c:46058: by v__builder__Builder_get_rest_of_module_cflags
/tmp/v_1000/v2.3929247846798868269.tmp.c:45908: by v__builder__Builder_build_thirdparty_obj_files
/tmp/v_1000/v2.3929247846798868269.tmp.c:45580: by v__builder__Builder_cc
/tmp/v_1000/v2.3929247846798868269.tmp.c:47015: by v__builder__cbuilder__compile_c
/tmp/v_1000/v2.3929247846798868269.tmp.c:46918: by v__builder__Builder_rebuild
/tmp/v_1000/v2.3929247846798868269.tmp.c:46076: by v__builder__compile
/tmp/v_1000/v2.3929247846798868269.tmp.c:47361: by main__rebuild
/tmp/v_1000/v2.3929247846798868269.tmp.c:47311: by main__main
/tmp/v_1000/v2.3929247846798868269.tmp.c:48027: by main
Exited with error status 1

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.2 95509cf

Environment details (OS name and version, etc.)

V full version: V 0.4.1 3a91a5e.0b0499b
OS: linux, Debian GNU/Linux 11 (bullseye) (VM)
Processor: 1 cpus, 64bit, little endian, Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz

getwd: /home/admin/playground
vexe: /home/admin/v/v
vexe mtime: 2023-09-16 11:21:36

vroot: OK, value: /home/admin/v
VMODULES: OK, value: /.vmodules
VTMP: OK, value: /tmp/v_0

Git version: git version 2.30.2
Git vroot status: Error: fatal: detected dubious ownership in repository at '/home/admin/v'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/admin/v
.git/config present: true

CC version: cc (Debian 10.2.1-6) 10.2.1 20210110
thirdparty/tcc status: Error: fatal: detected dubious ownership in repository at '/home/admin/v/thirdparty/tcc'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/admin/v/thirdparty/tcc
 Error: fatal: detected dubious ownership in repository at '/home/admin/v/thirdparty/tcc'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/admin/v/thirdparty/tcc

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

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

yochem · 2023-10-27T14:33:49Z

I get the same error on running v up:

Updating V...
> make failed:
> make output:
/Library/Developer/CommandLineTools/usr/bin/make fresh_vc
rm -rf ./vc
git clone --filter=blob:none --quiet https://github.com/vlang/vc ./vc
cd ./vc && git clean -xf && git pull --quiet
/Library/Developer/CommandLineTools/usr/bin/make fresh_tcc
rm -rf ./thirdparty/tcc
git clone --filter=blob:none --quiet --branch thirdparty-macos-amd64 https://github.com/vlang/tccbin ./thirdparty/tcc
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
./v1.exe -no-parallel -o v2.exe  cmd/v
./v2.exe -nocache -o /usr/local/Cellar/vlang/0.4.2/libexec/v  cmd/v
rm -rf v1.exe v2.exe
signal 11: segmentation fault
0   libsystem_platform.dylib            0x00007ff81577f37d _sigtramp + 29
1   ???                                 0x0000000000000000 0x0 + 0
2   v                                   0x0000000109a4302b os__Process__spawn + 155
3   v                                   0x0000000109a42f53 os__Process_wait + 35
4   v                                   0x0000000109d60e35 v__builder__Builder_run_compiled_executable_and_exit + 3701
5   v                                   0x0000000109d5e60c v__builder__compile + 124
6   v                                   0x0000000109d69fc9 main__rebuild + 121
7   v                                   0x0000000109d691d5 main__main + 2181
8   v                                   0x0000000109d6e940 main + 64
9   dyld                                0x00007ff8153c93a6 start + 1942
make: *** [all] Error 139

Current V version: V 0.4.2 b3b68e4, timestamp: 2023-10-27 12:27:54 +0300
Recompiling V *failed*.
Try running `make` .

V doctor:

V full version: V 0.4.2 b3b68e4
OS: macos, macOS, 14.0, 23A344
Processor: 4 cpus, 64bit, little endian, Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz

getwd: /usr/local
vexe: /usr/local/Cellar/vlang/0.4.2/libexec/v
vexe mtime: 2023-10-27 14:09:56

vroot: OK, value: /usr/local/Cellar/vlang/0.4.2/libexec
VMODULES: OK, value: /Users/yochem/.local/share/vmodules
VTMP: OK, value: /tmp/v_501

Git version: git version 2.42.0
Git vroot status: weekly.2023.43-29-gb3b68e41
.git/config present: true

CC version: Apple clang version 15.0.0 (clang-1500.0.40.1)
thirdparty/tcc status: thirdparty-macos-amd64 46662e20

shove70 · 2023-10-28T03:16:46Z

I get the same error on running v up:

Updating V...
> make failed:
> make output:
/Library/Developer/CommandLineTools/usr/bin/make fresh_vc
rm -rf ./vc
git clone --filter=blob:none --quiet https://github.com/vlang/vc ./vc
cd ./vc && git clean -xf && git pull --quiet
/Library/Developer/CommandLineTools/usr/bin/make fresh_tcc
rm -rf ./thirdparty/tcc
git clone --filter=blob:none --quiet --branch thirdparty-macos-amd64 https://github.com/vlang/tccbin ./thirdparty/tcc
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
./v1.exe -no-parallel -o v2.exe  cmd/v
./v2.exe -nocache -o /usr/local/Cellar/vlang/0.4.2/libexec/v  cmd/v
rm -rf v1.exe v2.exe
signal 11: segmentation fault
0   libsystem_platform.dylib            0x00007ff81577f37d _sigtramp + 29
1   ???                                 0x0000000000000000 0x0 + 0
2   v                                   0x0000000109a4302b os__Process__spawn + 155
3   v                                   0x0000000109a42f53 os__Process_wait + 35
4   v                                   0x0000000109d60e35 v__builder__Builder_run_compiled_executable_and_exit + 3701
5   v                                   0x0000000109d5e60c v__builder__compile + 124
6   v                                   0x0000000109d69fc9 main__rebuild + 121
7   v                                   0x0000000109d691d5 main__main + 2181
8   v                                   0x0000000109d6e940 main + 64
9   dyld                                0x00007ff8153c93a6 start + 1942
make: *** [all] Error 139

Current V version: V 0.4.2 b3b68e4, timestamp: 2023-10-27 12:27:54 +0300
Recompiling V *failed*.
Try running `make` .

V doctor:

V full version: V 0.4.2 b3b68e4
OS: macos, macOS, 14.0, 23A344
Processor: 4 cpus, 64bit, little endian, Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz

getwd: /usr/local
vexe: /usr/local/Cellar/vlang/0.4.2/libexec/v
vexe mtime: 2023-10-27 14:09:56

vroot: OK, value: /usr/local/Cellar/vlang/0.4.2/libexec
VMODULES: OK, value: /Users/yochem/.local/share/vmodules
VTMP: OK, value: /tmp/v_501

Git version: git version 2.42.0
Git vroot status: weekly.2023.43-29-gb3b68e41
.git/config present: true

CC version: Apple clang version 15.0.0 (clang-1500.0.40.1)
thirdparty/tcc status: thirdparty-macos-amd64 46662e20

Reference:
#19384

reidsneo · 2023-11-04T07:58:25Z

Hi me too!

v doctor ─╯
V full version: V 0.4.2 244411a
OS: macos, macOS, 14.1, 23B74
Processor: 8 cpus, 64bit, little endian, Apple M2

v run hello.v                                                                                                                                                                                                                                                                                                                                                                 ─╯
signal 11: segmentation fault
0   libsystem_platform.dylib            0x00007ff802e8a37d _sigtramp + 29
1   ???                                 0x0000000109b05080 0x0 + 4457517184
2   v                                   0x000000010085cefb os__Process__spawn + 155
3   v                                   0x000000010085ce23 os__Process_wait + 35
4   v                                   0x0000000100b7b9d5 v__builder__Builder_run_compiled_executable_and_exit + 3701
5   v                                   0x0000000100b791ac v__builder__compile + 124
6   v                                   0x0000000100b84b69 main__rebuild + 121
7   v                                   0x0000000100b83d75 main__main + 2181
8   v                                   0x0000000100b896b0 main + 64
9   dyld                                0x0000000200eab3a6 start + 1942


./hello                                                                                                                                                                                                                                                                                                                                                                       ─╯
Hello, Playground!



v up                                                                                                                                                                                                                                                                                                                                                                          ─╯
Updating V...
V is already updated.
Current V version: V 0.4.2 244411a, timestamp: 2023-11-04 08:00:37 +0200

I can't even run the compiled ./hello
but after switching to x86_64 using rosetta 2 I was able to

arch -x86_64 ./hello

but still cannot do on compiling
arch -x86_64 v run hello.v

Update, it seem the binary in the main web page for mac is not correctly compiled for arm64
I tried to recompile the V from source, now working good

Casper64 · 2023-11-04T13:28:45Z

Hey, this is not a bug, but a confusing part of vweb. You need to add the vweb_global attribute to your Middleware struct. Long story short, each time a request is handled your vweb app struct gets "reset", that is why you ended up with a segmentation fault.
If you want to prevent certain properties from "resetting" you have to add the vweb_global attribute.
Read more about why here.

struct Middleware {
	vweb.Context
	pinger Pinger [vweb_global]
}

Work is being doing in a new version of vweb to eliminate the need for this attribute, but that will take some time.

axpira added the Bug This tag is applied to issues which reports bugs. label Oct 25, 2023

ArtemkaKun added Unit: vweb Bugs/feature requests, that are related to the `vweb`. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. labels Oct 25, 2023

Casper64 closed this as completed Nov 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

signal 11: segmentation fault when have field on struct #19652

signal 11: segmentation fault when have field on struct #19652

axpira commented Oct 25, 2023 •

edited by github-actions bot

Loading

yochem commented Oct 27, 2023

shove70 commented Oct 28, 2023

reidsneo commented Nov 4, 2023 •

edited

Loading

Casper64 commented Nov 4, 2023 •

edited

Loading

signal 11: segmentation fault when have field on struct #19652

signal 11: segmentation fault when have field on struct #19652

Comments

axpira commented Oct 25, 2023 • edited by github-actions bot Loading

Describe the bug

Reproduction Steps

Expected Behavior

Current Behavior

Possible Solution

Additional Information/Context

V version

Environment details (OS name and version, etc.)

yochem commented Oct 27, 2023

shove70 commented Oct 28, 2023

reidsneo commented Nov 4, 2023 • edited Loading

Casper64 commented Nov 4, 2023 • edited Loading

axpira commented Oct 25, 2023 •

edited by github-actions bot

Loading

reidsneo commented Nov 4, 2023 •

edited

Loading

Casper64 commented Nov 4, 2023 •

edited

Loading