30 Aug
2007
30 Aug
'07
8:52 a.m.
Hi all,
I'm trying to run openser 1.2.2 on Linux, but
I obtain alway a segfault while loading module.
The gdb shows:
Program terminated with signal 11, Segmentation fault.
#0 pg_free_row (_row=0x785bc8) at db_res.c:575
575 switch (VAL_TYPE(_val)) {
I've a complex configuration, but the problem arise early so
I don't think it's a configuration issue.
The last messages I got in the log are:
openser[31824]: PG[free_query]: PQclear(0x863a70) result set
openser[31824]: PG[free_columns]: Freeing RES_NAMES(0x785b20)[0] -> free(0x785b90)
'table_version'
openser[31824]: PG[free_columns]: 0x785b90=pkg_free() RES_NAMES[0]
openser[31824]: PG[free_columns]: 0x785b60=pkg_free() RES_NAMES
openser[31824]: PG[free_columns]: 0x785b78=pkg_free() RES_TYPES
openser[31824]: PG[free_rows]: Freeing 1 rows
openser[31824]: PG[free_rows]: Row[0]=0x785bc8
The last query I could see in the database is
"select table_version from version where table_name='domain'"
(it returns 1)
I use postgres 8.2.4 on Linux 2.6.18 with xen, and gcc 4.1.3.
Could someone suggest how I can investigate further?
TIA,
--
"Work and play are words used to
describe the same thing under
differing conditions." Mark Twain
http://people.equars.com/blogs/marco
30 Aug
30 Aug
9:02 a.m.
On Thursday 30 August 2007, Marco wrote:
Hi all,
I'm trying to run openser 1.2.2 on Linux, but
I obtain alway a segfault while loading module.
The gdb shows:
Program terminated with signal 11, Segmentation fault.
#0 pg_free_row (_row=0x785bc8) at db_res.c:575
575 switch (VAL_TYPE(_val)) {
Hello Marc,
could you please provide a full backtrace from the core dump?
Cheers,
Henning
9:19 a.m.
On Thu, Aug 30, 2007 at 03:02:33PM +0200, Henning Westerholt wrote:
Hello Marc,
could you please provide a full backtrace from the core dump?
Here it is:
#0 pg_free_row (_row=0x785bc8) at db_res.c:575
#1 0x00002b95086b41eb in pg_free_rows (_res=0x785b20) at db_res.c:541
#2 0x00002b95086b4376 in pg_free_result (_res=0x785b20) at db_res.c:654
#3 0x00002b95086b1647 in pg_free_query (_con=0x7859d8, _r=0x785b20)
at dbase.c:595
#4 0x000000000049b628 in table_version (dbf=0x2b950a9a0c80,
connection=0x7859d8, table=0x2b950a9a09f0) at db/db.c:212
#5 0x00002b950a79de42 in mod_init () at domain_mod.c:159
#6 0x0000000000457fbd in init_mod (m=0x752cc0) at sr_module.c:463
#7 0x0000000000457f76 in init_mod (m=0x7533b0) at sr_module.c:458
#8 0x0000000000457f76 in init_mod (m=0x754040) at sr_module.c:458
#9 0x0000000000457f76 in init_mod (m=0x754100) at sr_module.c:458
#10 0x0000000000457f76 in init_mod (m=0x7547f0) at sr_module.c:458
#11 0x0000000000457f76 in init_mod (m=0x7548b0) at sr_module.c:458
#12 0x0000000000457f76 in init_mod (m=0x755930) at sr_module.c:458
#13 0x0000000000457f76 in init_mod (m=0x755e70) at sr_module.c:458
#14 0x0000000000457f76 in init_mod (m=0x756b90) at sr_module.c:458
#15 0x0000000000457f76 in init_mod (m=0x757c10) at sr_module.c:458
#16 0x0000000000457f76 in init_mod (m=0x758b70) at sr_module.c:458
#17 0x0000000000457f76 in init_mod (m=0x758de0) at sr_module.c:458
#18 0x0000000000457f76 in init_mod (m=0x75a370) at sr_module.c:458
#19 0x0000000000457f76 in init_mod (m=0x75c4d0) at sr_module.c:458
#20 0x0000000000457f76 in init_mod (m=0x75cac8) at sr_module.c:458
#21 0x0000000000457f76 in init_mod (m=0x75d518) at sr_module.c:458
#22 0x0000000000457f76 in init_mod (m=0x75dae8) at sr_module.c:458
#23 0x000000000042f03b in main (argc=<value optimized out>,
argv=<value optimized out>) at main.c:1381
Thanks for your answer.
Ciao,
--
"Work and play are words used to
describe the same thing under
differing conditions." Mark Twain
http://people.equars.com/blogs/marco
9:27 a.m.
On Thursday 30 August 2007, Marco wrote:
As Norman wrote, this was fixed in revision 2618. BTW, i introduced this bug,
sorry. :-/
You could either update to the stable 1.2 branch from svn, or apply a patch to
get this fix. This is the commit in question:
http://openser.svn.sourceforge.net/openser/?rev=2618&view=rev
Please report if this don't fix your problem.
Cheers,
Henning
could you
please provide a full backtrace from the core dump?
Here it is:
#0 pg_free_row (_row=0x785bc8) at db_res.c:575
#1 0x00002b95086b41eb in pg_free_rows (_res=0x785b20) at db_res.c:541
#2 0x00002b95086b4376 in pg_free_result (_res=0x785b20) at db_res.c:654
[..]
9:45 a.m.
On Thu, Aug 30, 2007 at 03:27:04PM +0200, Henning Westerholt wrote:
As Norman wrote, this was fixed in revision 2618. BTW,
i introduced this bug,
sorry. :-/
You could either update to the stable 1.2 branch from svn, or apply a patch to
get this fix. This is the commit in question:
http://openser.svn.sourceforge.net/openser/?rev=2618&view=rev
Please report if this don't fix your problem.
Yes, it works.
Thanks a lot!
Ciao,
--
"Work and play are words used to
describe the same thing under
differing conditions." Mark Twain
http://people.equars.com/blogs/marco
9:02 a.m.
Hi Marco,
The resolution to this problem is located here:
http://openser.org/pipermail/users/2007-August/012646.html
It has been fixed on the SVN version of the code.
Regards,
Norm
Marco wrote:
Hi all,
I'm trying to run openser 1.2.2 on Linux, but
I obtain alway a segfault while loading module.
The gdb shows:
Program terminated with signal 11, Segmentation fault.
#0 pg_free_row (_row=0x785bc8) at db_res.c:575
575 switch (VAL_TYPE(_val)) {
I've a complex configuration, but the problem arise early so
I don't think it's a configuration issue.
The last messages I got in the log are:
openser[31824]: PG[free_query]: PQclear(0x863a70) result set
openser[31824]: PG[free_columns]: Freeing RES_NAMES(0x785b20)[0] -> free(0x785b90)
'table_version'
openser[31824]: PG[free_columns]: 0x785b90=pkg_free() RES_NAMES[0]
openser[31824]: PG[free_columns]: 0x785b60=pkg_free() RES_NAMES
openser[31824]: PG[free_columns]: 0x785b78=pkg_free() RES_TYPES
openser[31824]: PG[free_rows]: Freeing 1 rows
openser[31824]: PG[free_rows]: Row[0]=0x785bc8
The last query I could see in the database is
"select table_version from version where table_name='domain'"
(it returns 1)
I use postgres 8.2.4 on Linux 2.6.18 with xen, and gcc 4.1.3.
Could someone suggest how I can investigate further?
TIA,
6381
days inactive
6381
days old
5 comments
3 participants
participants (3)
-
Henning Westerholt -
Marco -
Norman Brandinger