Skip to content
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.

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

record field not initialized correctly with { expr with ... } record initialization #7076

Closed
vicuna opened this issue Dec 4, 2015 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Dec 4, 2015

Original bug ID: 7076
Reporter: madroach
Assigned to: @yallop
Status: closed (set by @yallop on 2015-12-04T22:17:16Z)
Resolution: not a bug
Priority: normal
Severity: major
Platform: amd64
OS: OpenBSD
OS Version: -current
Version: 4.02.3
Category: back end (clambda to assembly)
Tags: suggest_closing
Monitored by: @gasche

Bug description

When constructing a new record via { header with extra = header.extra } notation the last record field (name) is not initialized correctly. The bug only triggers when no more than one field is specified in the implicit record construction.

(* Type of the record *)
type header =
{ text :bool
; mtime :float
; os :int
; xflags :int
; extra :string option
; comment :string option
; name :string option
}

(* OCaml code triggering the bug *)
print_header header;
dumph header;
dump header.name;
let header =
{
header with
extra = header.extra
} in
dumph header;
dump header.name;

Output when running the code:

print_header

header:
text: true
mtime: 1449251764.000000
os: 3
xflags: 0
extra: 23<Some "This is an extra string">
comment: 19<Some "This is the comment">
name: 20<Some "This is the filename">

dumph header just outputs [Field number]=[binary value]

0=0x3 1=0xe7c6c004a00 2=0x7 3=0x1 4=0xe7c6c004a70 5=0xe7c6c004a40 6=0xe7c6c004a10

dump header.name outputs the header of the option value and extracts wosize

Option(0xe7c6c004a08): Header: 0x0000000000000700 (wosize 1)

and the same for the string.

String(0xe7c6c004a18): Header: 0x0000000000000ffc (wosize 3) len: 20 string:

dumph header again. This time the last (name) field contains an invalid pointer

0=0x3 1=0xe7c6c004a00 2=0x7 3=0x1 4=0xe7c6c004a70 5=0xe7c6c004a40 6=0x707

which will trigger a segfault in dump header.name

Option(0x6ff): Segmentation fault

Steps to reproduce

The whole project (zlib binding) is attached. It depends on oasis. Just call make test.

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 4, 2015

Comment author: madroach

The bug was in my c stubs. Sorry for spamming the bugtracker.
This report can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant