After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703996 - Vala assumes that structs can be copied or destructor can be called on uninitialized struct
Vala assumes that structs can be copied or destructor can be called on uninit...
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Code Generator
unspecified
Other Linux
: Normal major
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-11 11:44 UTC by Maciej (Matthew) Piechotka
Modified: 2014-06-03 18:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Maciej (Matthew) Piechotka 2013-07-11 11:44:23 UTC
For example the following code:

[Compact]
public class Node<K, V> {
    public WeakRef x = WeakRef(null);
}

results in following code:

static void node_instance_init (Node * self) {
	GWeakRef _tmp0_ = {0};
	g_weak_ref_init (&_tmp0_, NULL);
	self->x = _tmp0_;
}

Which is illegal as weak references need to know exact location of the struct. Moving initialization to constructor helps to some extend:

Node* node_new (void) {
	Node* self;
	self = g_slice_new0 (Node);
	node_instance_init (self);
	g_weak_ref_clear (&self->x); // We destruct an object which wasn't constructed
	g_weak_ref_init (&self->x, NULL);
	return self;
}


static void node_instance_init (Node * self) {
}
Comment 1 Luca Bruno 2014-01-04 17:06:46 UTC
What about [CCode (lvalue_access = false)] on top of WeakRef?
Comment 2 Maciej (Matthew) Piechotka 2014-01-11 14:09:58 UTC
No change with Vala from master
Comment 3 Luca Bruno 2014-01-11 14:27:50 UTC
Right for instance variable initializer, however if you do that from a constructor it works.
Comment 4 Maciej (Matthew) Piechotka 2014-01-11 14:29:32 UTC
The code's identical so it still clears the variable
Comment 5 Luca Bruno 2014-01-11 14:58:42 UTC
The code I get in the init is:

g_weak_ref_clear (&self->x);
g_weak_ref_init (&self->x, NULL);

And in fini:

g_weak_ref_clear (&self->x);

Isn't that what you expect?
Comment 6 Maciej (Matthew) Piechotka 2014-01-11 16:44:23 UTC
(In reply to comment #5)
> The code I get in the init is:
> 
> g_weak_ref_clear (&self->x);
> g_weak_ref_init (&self->x, NULL);
> 
> And in fini:
> 
> g_weak_ref_clear (&self->x);
> 
> Isn't that what you expect?

No - the constructor clears the struct which wasn't constructed, which probably should not happen.
Comment 7 Luca Bruno 2014-01-11 23:36:29 UTC
Why not? It shouldn't cause any problem.
Comment 8 Luca Bruno 2014-01-25 11:05:04 UTC
Do we have a test case that fails deterministically so I can add a regression test?
Comment 9 Nor Jaidi Tuah 2014-05-29 02:27:10 UTC
Regarding this code:
> The code I get in the init is:
> 
> g_weak_ref_clear (&self->x);
> g_weak_ref_init (&self->x, NULL);


The GObject reference manual at

   https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-weak-ref-clear

states concerning g_weak_ref_clear

   "You should only call this on a GWeakRef that previously had g_weak_ref_init() called on it."
Comment 10 Luca Bruno 2014-06-01 10:16:16 UTC
Ok then, the field initialization in classes have to take in account lvalue_access = false.
Comment 11 Luca Bruno 2014-06-03 18:34:31 UTC
commit 02c7a414e00dc8e79c4cb9ad6c0c436df26c8dd5
Author: Luca Bruno <luca.bruno@immobiliare.it>
Date:   Tue Jun 3 11:57:07 2014 +0200

    codegen: Simplify field initialization for struct types
    
    Fixes bug 703996

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.