8000 The unix version crashes · Issue #38 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

The unix version crashes #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Chananyah opened this issue Jan 2, 2014 · 8 comments
Closed

The unix version crashes #38

Chananyah opened this issue Jan 2, 2014 · 8 comments
Labels
bug

Comments

@Chananyah
Copy link

The following code results in segmentation fault:

gen = (i for i in range(10))
for i in gen: print(i)

Compiling with debugging symbols (-g) and running though gdb gives this:

Current directory is /home/alex/micropython/unix/
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/alex/micropython/unix/py...done.
(gdb) run
Starting program: /home/alex/micropython/unix/py

gen = (i for i in range(10))
gen.next()

Program received signal SIGSEGV, Segmentation fault.
0x000000000041acbf in mp_obj_print_helper (print=0x41abcd <printf_wrapper>, env=0x0, o_in=0x64fe30) at ../py/obj.c:40
(gdb) where
#0  0x000000000041acbf in mp_obj_print_helper (print=0x41abcd <printf_wrapper>, env=0x0, o_in=0x64fe30) at ../py/obj.c:40
#1  0x000000000041ad2c in mp_obj_print (o_in=0x64fe30) at ../py/obj.c:49
#2  0x000000000041e82b in mp_builtin___repl_print__ (o=0x64fe30) at ../py/builtin.c:45
#3  0x000000000041c534 in fun_native_call_n (self_in=0x635030, n_args=1, args=0x7fffffffe350) at ../py/objfun.c:35
#4  0x0000000000419cea in rt_call_function_n (fun_in=0x635030, n_args=1, args=0x7fffffffe350) at ../py/runtime.c:698
#5  0x0000000000421148 in mp_execute_byte_code_2 (ip_in_out=0x7fffffffe300, fastn=0x7fffffffe310, sp_in_out=0x7fffffffe2f8) at ../py/vm.c:435
#6  0x000000000041f9a5 in mp_execute_byte_code (code=0x6502c0 "", args=0x0, n_args=0, n_state=2) at ../py/vm.c:56
#7  0x000000000041c8a8 in fun_bc_call_n (self_in=0x652580, n_args=0, args=0x0) at ../py/objfun.c:145
#8  0x0000000000419cea in rt_call_function_n (fun_in=0x652580, n_args=0, args=0x0) at ../py/runtime.c:698
#9  0x0000000000419c1a in rt_call_function_0 (fun=0x652580) at ../py/runtime.c:672
#10 0x0000000000400fef in do_repl () at main.c:94
#11 0x00000000004011ec in main (argc=1, argv=0x7fffffffe5c8) at main.c:215
(gdb)
@Dr-Syn
Copy link
Contributor
Dr-Syn commented Jan 2, 2014

I see you're using Ubuntu; which version do you have, so I can replicate?

@Chananyah
Copy link
Author

OS is
ubuntu 13.04 (GNU/Linux 3.8.0-34-generic x86_64)

gcc --version gives
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

@hagenkaye
Copy link
Contributor

just as a side note. It seems the stack trace made github markdown go crazy and link this post with others. I tried to edit by putting a code fence block around the stack trace, but the links are still there.

@dpgeorge
Copy link
Member
dpgeorge commented Jan 2, 2014

Yes, this is a bug. It doesn't crash for me, but prints the wrong number (10 times).

If you want to try and fix it, enable debug output in runtime.c, at line 20. Then run the example again.

@Dr-Syn
Copy link
Contributor
Dr-Syn commented Jan 2, 2014

I can confirm that the above program listing will segfault on ubuntu 12.04 using GCC.

Using that setup, with the runtime.c debug output, I get:

store name test <- 0x94da7e0
assign byte code: id=1 code=0x94daca8 len=36 n_args=0
 00 90 02 25 27 13 0a 00 80 92 01 52 92 01 35 2c
 25 2c 52 53 0c 00 35 2d 25 26 25 2d 92 01 42 45
 f1 7f 11 80
(NUM_LOCAL 0)
00 MAKE_FUNCTION 2
02 LOAD_NAME range
04 LOAD_CONST_SMALL_INT 10
08 CALL_FUNCTION n=1 nkw=0
10 GET_ITER
11 CALL_FUNCTION n=1 nkw=0
13 STORE_NAME gen
15 LOAD_NAME gen
17 GET_ITER
18 FOR_ITER 33
21 STORE_NAME i
23 LOAD_NAME print
25 LOAD_NAME i
27 CALL_FUNCTION n=1 nkw=0
29 POP_TOP
30 JUMP 18
33 LOAD_CONST_NONE
34 RETURN_VALUE
assign byte code: id=2 code=0x94dac68 len=14 n_args=1
 00 20 53 07 00 31 21 82 42 45 f6 7f 11 80
(NUM_LOCAL 0)
00 LOAD_FAST_0
01 FOR_ITER 11
04 STORE_FAST_1
05 LOAD_FAST_1
06 YIELD_VALUE
07 POP_TOP
08 JUMP 1
11 LOAD_CONST_NONE
12 RETURN_VALUE
make_function_from_id 1
calling function 0x94dbfc8(n_args=0, args=(nil))
make_function_from_id 2
load name range
calling function 0x94daa68(n_args=1, args=0xbf819d3c)
calling function 0x94dac18(n_args=1, args=0xbf819d40)
store name gen <- 0x94dc038
load name gen
store name i <- (nil)
load name print
load name i
calling function 0x94daa50(n_args=1, args=0xbf819d3c)
Segmentation fault

@Dr-Syn
Copy link
Contributor
Dr-Syn commented Jan 2, 2014

And interestingly enough, changing the generator function in the original code to

gen = (1*i for i in range(10))

results in a successful test, returning 0 through 9 as expected.

dpgeorge added a commit that referenced this issue Jan 2, 2014
@dpgeorge
py: Fix generator where state array was incorrectly indexed.
0ff8839 
Generator objects now allocate the object and the state in one malloc.
This improvement fixes Issue #38.
@dpgeorge dpgeorge closed this as completed Jan 2, 2014
@Dr-Syn
Copy link
Contributor
Dr-Syn commented Jan 2, 2014

Also, using the list comprehension, as:

gen = [i for i in range(10)]

will work just fine and dandy. For some reason, it just doesn't like the naked variable sitting there without something happening to it.

Update: go figure while I'm digging around that you fix it. :-)

@dpgeorge
Copy link
Member
dpgeorge commented Jan 2, 2014

It was a pretty nasty bug: I allocated enough memory for the state of the generator (to hold local variables and the stack), but I initialised the stack pointer to the last element, when it should be initialised to the position just after the last element of the state. This is because the stack is pre-decrement

Sorry if I spoiled your fun!

turbinenreiter pushed a commit to turbinenreiter/micropython that referenced this issue Oct 31, 2016
@tannewt
Merge pull request micropython#38 from tannewt/autoreset
04284a9 
atmel-samd: Support auto-reset based on USB write activity.
drrk pushed a commit to drrk/micropython that referenced this issue Jan 22, 2017
@mattbrejza
Merge pull request micropython#38 from emfcamp/ugfx-deinit-improvements
677a669 
closes files on deinit
tannewt pushed a commit to tannewt/circuitpython that referenced this issue Jan 23, 2021
@DavePutz
Merge pull request micropython#38 from adafruit/main
e424c84 
Update from adafruit main
WeActStudio pushed a commit to WeActStudio/micropython that referenced this issue Feb 14, 2021
@iabdalkader
Merge pull request micropython#38 from kwagyeman/openmv
25d25a9 
Cleanup fballoc stack on NLR.
TinyCircuits added a commit to TinyCircuits/micropython that referenced this issue Jan 30, 2025
@TinyCircuits
Merge pull request micropython#38 from TinyCircuits/color
02200be 
Replaced the Color implementation to storing a single 16bit value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@hagenkaye @dpgeorge @Dr-Syn @Chananyah
0