GNOME Bugzilla – Bug 542235
Bug in binding for sqlite:get_table
Last modified: 2008-07-30 21:48:04 UTC
Please describe the problem: When I try to compile the get_table function of the sqlite bindings the C-compiler says: --------------------------------------------------------- SqliteVala3.c: In Funktion »file_access_checkCreateDb«: SqliteVala3.c:551: Warnung: Übergabe des Arguments 6 von »sqlite3_get_table« von inkompatiblem Zeigertyp (wrong pointer type for argument 6 of »sqlite3_get_table«) SqliteVala3.c:551: Fehler: zu viele Argumente für Funktion »sqlite3_get_table« error: cc exited with status 256 (Error: Too many arguments for function »sqlite3_get_table« ...) Compilation failed: 1 error(s), 0 warning(s) ------------------------------------------------------------- The vala code is something like this: private void checkCreateDb () { string CURRENT_QUERY = ""; string errmsg; int rc,nrow,ncolumn; string[] resultArray; RecordStringList = new List<string> (); CURRENT_QUERY = "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"; rc = db.get_table(CURRENT_QUERY, out resultArray, ref nrow, ref ncolumn, out errmsg); ..... .... Steps to reproduce: happens every time Actual results: The above C-Compiler message is shown Expected results: Does this happen every time? yes Other information: vala 0.3.4
The error is in the sqlite binding. Must add [NoArrayLength] before get_table and free_table to make this work.... You can do this manually, but someone can change this in the repositories files? thanks!!
adding the [NoArrayLength] in the vapi before the get_table and the free_table function made it it popssible to compile, but the execution of the program (just that simple query and then freeing, everything else commented out) led to a hard crash. Backtrace: *** glibc detected *** ./vvv: free(): invalid pointer: 0x08056bc4 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7c24a85] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c284f0] /usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb7e2a8b1] ./vvv[0x804b82a] ./vvv[0x804b2b4] ./vvv[0x804b2d6] ./vvv[0x804b324] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7bcf450] ./vvv[0x8049331] ======= Memory map: ======== 08048000-0804c000 r-xp 00000000 08:02 157318 /home/qnull/Desktop/Programmieren/VALA/vvv 0804c000-0804d000 rw-p 00003000 08:02 157318 /home/qnull/Desktop/Programmieren/VALA/vvv 0804d000-0806e000 rw-p 0804d000 00:00 0 [heap] b6900000-b6921000 rw-p b6900000 00:00 0 b6921000-b6a00000 ---p b6921000 00:00 0 b6a20000-b6a21000 ---p b6a20000 00:00 0 b6a21000-b7221000 rw-p b6a21000 00:00 0 b7221000-b7222000 ---p b7221000 00:00 0 b7222000-b7a23000 rw-p b7222000 00:00 0 b7a23000-b7a2d000 r-xp 00000000 08:01 32704 /lib/libgcc_s.so.1 b7a2d000-b7a2e000 rw-p 0000a000 08:01 32704 /lib/libgcc_s.so.1 b7a2e000-b7a2f000 rw-p b7a2e000 00:00 0 b7a2f000-b7a52000 r-xp 00000000 08:01 50307 /lib/tls/i686/cmov/libm-2.7.so b7a52000-b7a54000 rw-p 00023000 08:01 50307 /lib/tls/i686/cmov/libm-2.7.so b7a54000-b7b3c000 r-xp 00000000 08:01 59226 /usr/lib/libstdc++.so.6.0.9 b7b3c000-b7b3f000 r--p 000e8000 08:01 59226 /usr/lib/libstdc++.so.6.0.9 b7b3f000-b7b41000 rw-p 000eb000 08:01 59226 /usr/lib/libstdc++.so.6.0.9 b7b41000-b7b47000 rw-p b7b41000 00:00 0 b7b47000-b7b5b000 r-xp 00000000 08:01 59301 /usr/lib/libz.so.1.2.3.3 b7b5b000-b7b5c000 rw-p 00013000 08:01 59301 /usr/lib/libz.so.1.2.3.3 b7b5c000-b7b70000 r-xp 00000000 08:01 50325 /lib/tls/i686/cmov/libpthread-2.7.so b7b70000-b7b72000 rw-p 00013000 08:01 50325 /lib/tls/i686/cmov/libpthread-2.7.so b7b72000-b7b74000 rw-p b7b72000 00:00 0 b7b74000-b7b76000 r-xp 00000000 08:01 50305 /lib/tls/i686/cmov/libdl-2.7.so b7b76000-b7b78000 rw-p 00001000 08:01 50305 /lib/tls/i686/cmov/libdl-2.7.so b7b78000-b7b79000 rw-p b7b78000 00:00 0 b7b79000-b7b9f000 r-xp 00000000 08:01 59107 /usr/lib/libpcre.so.3.12.1 b7b9f000-b7ba0000 rw-p 00026000 08:01 59107 /usr/lib/libpcre.so.3.12.1 b7ba0000-b7bb7000 r-xp 00000000 08:01 32765 /lib/libselinux.so.1 b7bb7000-b7bb9000 rw-p 00016000 08:01 32765 /lib/libselinux.so.1 b7bb9000-b7d02000 r-xp 00000000 08:01 50299 /lib/tls/i686/cmov/libc-2.7.so b7d02000-b7d03000 r--p 00149000 08:01 50299 /lib/tls/i686/cmov/libc-2.7.so b7d03000-b7d05000 rw-p 0014a000 08:01 50299 /lib/tls/i686/cmov/libc-2.7.so b7d05000-b7d08000 rw-p b7d05000 00:00 0 b7d08000-b7d7e000 r-xp 00000000 08:01 125663 /usr/local/lib/libtag.so.1.5.0 b7d7e000-b7d80000 rw-p 00076000 08:01 125663 /usr/local/lib/libtag.so.1.5.0 b7d80000-b7d84000 r-xp 00000000 08:01 125667 /usr/local/lib/libtag_c.so.0.0.0 b7d84000-b7d85000 rw-p 00003000 08:01 125667 /usr/local/lib/libtag_c.so.0.0.0 b7d85000-b7de8000 r-xp 00000000 08:01 59220 /usr/lib/libsqlite3.so.0.8.6 b7de8000-b7dea000 rw-p 00062000 08:01 59220 /usr/lib/libsqlite3.so.0.8.6 b7dea000-b7deb000 rw-p b7dea000 00:00 0 b7deb000-b7e9b000 r-xp 00000000 08:01 59740 /usr/lib/libglib-2.0.so.0.1600.3 b7e9b000-b7e9c000 rw-p 000b0000 08:01 59740 /usr/lib/libglib-2.0.so.0.1600.3 b7e9c000-b7ed7000 r-xp 00000000 08:01 410763 /usr/lib/libgobject-2.0.so.0.1600.3 b7ed7000-b7ed8000 rw-p 0003b000 08:01 410763 /usr/lib/libgobject-2.0.so.0.1600.3 b7eef000-b7ef1000 rw-p b7eef000 00:00 0 b7ef1000-b7ef2000 r-xp b7ef1000 00:00 0 [vdso] b7ef2000-b7f0c000 r-xp 00000000 08:01 32659 /lib/ld-2.7.so b7f0c000-b7f0e000 rw-p 00019000 08:01 32659 /lib/ld-2.7.so bf94f000-bf964000 rw-p bffeb000 00:00 0 [stack] Aborted (In reply to comment #1) > The error is in the sqlite binding. Must add [NoArrayLength] before get_table > and free_table to make this work.... > > > You can do this manually, but someone can change this in the repositories > files? > > thanks!! >
Ok, I see. I think that resultArray still have the address of the result table created with get_table and 'free' (from glibc) tries to free resultArray. If you see the source code in C you will find this at the end of the function: resultArray = (_vala_array_free (resultArray, resultArray_length1, ((GDestroyNotify) (g_free))), NULL); with this 'free' tries to free the memory, but if still contains the address of the result table the program will crash. I suggest to use pointers... Or something else..
I post a message in the maillist: http://www.mail-archive.com/vala-list@gnome.org/msg00900.html
Is this somehow related to this bug? -> http://bugzilla.gnome.org/show_bug.cgi?id=540823 -----------------------------------------------------
Try this: Change get_table and free_table of sqlite3.vapi with this: [NoArrayLength] public int get_table (string sql, out weak string[] resultp, ref int nrow, ref int ncolumn, out weak string errmsg); [NoArrayLength] public static void free_table (weak string[] result); and use this code: Database db; string CURRENT_QUERY = ""; int rc,nrow,ncolumn; weak string[] resultArray; weak string errmsg; CURRENT_QUERY = "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"; rc = db.get_table(CURRENT_QUERY, out resultArray, ref nrow, ref ncolumn, out errmsg); I hope thas this work!! seeing the C code i think may work because vala do not manage resultArray and errmsg. Try It and tell me!!
Thanks for answering! I tried it but I had no success. ----------------------------- Vala compiler says: -- sqlite3.vapi:42.45-42.45: error: syntax error, expected `)' public static void free_table (weak string[] result); ^ Compilation failed: 1 error(s), 0 warning(s) -----------------------------
Oh!! my mistake. Remove weak from the free_table function in the binding.
With this change a warning remains: ------------------------------------ SqliteVala3.c: In Funktion »file_access_checkCreateDb«: SqliteVala3.c:543: Warnung: Übergabe des Arguments 6 von »sqlite3_get_table« von inkompatiblem Zeigertyp (wrong pointer type for argument 6 of »sqlite3_get_table«) ------------------------------------ The C-code is something like this: ------------------------------------ ... CURRENT_QUERY = g_strdup (""); rc = 0; nrow = 0; ncolumn = 0; resultArray = (resultArray_length1 = 0, NULL); errmsg = NULL; _tmp0 = NULL; CURRENT_QUERY = (_tmp0 = g_strdup ("SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"), (CURRENT_QUERY = (g_free (CURRENT_QUERY), NULL)), _tmp0); rc = sqlite3_get_table (self->priv->db, CURRENT_QUERY, &resultArray, &nrow, &ncolumn, &errmsg); CURRENT_QUERY = (g_free (CURRENT_QUERY), NULL); ... ------------------------------------
...and the queries dont return any result. resultArray.length is always 0
yo can't use resultArray.length because get_table doesn't manage the length of resultArray, you have to use something else. The length of resultArray (in the c code) is in resultArray_length1. get_table "see" resultArray as a pointer. What is the utility of nrow and ncolumn? You have a C code (not created with valac) that work with get_table and free_table?
Sorry, I used the *.length the wrong way. the nrow and ncolumn got their values right and I was able to get the results of the query. Thank you very much! Looks like you fixed this bug. Just the pointer type warning remains there at compile time. Thank you for your patience Matias! ---------------------------------------------------------------
Great!! I will communicate to the maintainers to add this fix!! About the warning, that strange I don't receive any warning. errormsg is weak? Well isn't a big deal
Finally I'd like to post a summary here. Now without any warnings and full functionality. Vapi-Code: ----------------------------------------------- [NoArrayLength] public int get_table (string sql, out weak string[] resultp, ref int nrow, ref int ncolumn, out string errmsg); [NoArrayLength] public static void free_table (string[] result); ----------------------------------------------- Application code: ----------------------------------------------- string current_query = ""; int rc1,nrow,ncolumn; weak string[] resultArray; string errmsg; current_query = "SELECT * FROM folders;"; rc1 = db.get_table(current_query, out resultArray, ref nrow, ref ncolumn, out errmsg); ---------------------------------------------- Thanks again for the help! Maybe someone can add these changes to vala.
*** Bug 540823 has been marked as a duplicate of this bug. ***
2008-07-30 Jürg Billeter <j@bitron.ch> * vapi/sqlite3.vapi: Fix sqlite3_get_table and sqlite3_free_table bindings, still requires manual memory management, fixes bug 542235 Fixed in r1729.