python in free(): warning: page is already free

[hpdl@…]

Once or twice a week our Trac development server goes down due to the following error being repeatedly added to the error log, and it filling the /var partition:

python in free(): warning: page is already free

Our server is running on FreeBSD 6.1 AMD64 with the following packages installed:

Trac 0.10dev r3623
apache-2.2.3
clearsilver-0.10.3 (compiled manually with gmake)
enscript-a4-1.6.4_1
mod_fastcgi-2.4.2_1
python-2.4.3
silvercity-0.9.6
sqlite-3.3.7
subversion-1.3.2
subversion-python-1.3.2

A backtrace of the coredump provided is:

#0  0x0000000800b1d81c in pthread_testcancel () from /usr/lib/libpthread.so.2
#1  0x0000000800b0c080 in sigaction () from /usr/lib/libpthread.so.2
#2  0x0000000800b1601a in pthread_mutexattr_init () from /usr/lib/libpthread.so.2
#3  0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fffffbff000

Any pointers to fix this is appreciated. Thanks!

[Christian Boos]

Which PySqlite? A recent one, like 2.3.2? Also, be sure to compile SQLite with proper multi-threading support (see PySqlite#BuildingSQLiteyourself). In the same spirit, have you compiled Clearsilver with proper multithread support (see ClearSilver#Buildingthepackageyourself). The stack trace does indicate a problem with the threading, so I suspect that either one of the above package is not multithread safe.

[anonymous]

I had the following installed:

py24-pysqlite-2.0.7_1

and just updated to:

py24-pysqlite-2.3.2

By installing the newer version I had to afterwards delete the 2.0.7_1 version. Trac still works after restarting Apache (just incase it was needed)

ClearSilver was indeed compiled by hand using gmake, and made sure that the "Checking pthread.h… yes" line appeared during the configuration.

I don't know if upgrading the py24-pysqlite version will fix the problem - I hope so! I will report back when the same problems are experienced again (and will report back also if the problem seems to be solved).

Thanks for your help here - it is much appreciated!

[anonymous]

Thanks for pointing that out aswell → I just noticed the default flags for installing sqlite3 on FreeBSD have the threading support disabled. I just installed this port again with threads enabled and hope this fixes the problems we have been experiencing.

Thanks again!

[anonymous]

Core dumps are still unfortunately being made but no more repetitive error messages are being written to the error log file, which means the server continues to run without additional problems.

The same backtrace is being shown on the coredump but the message written to the main apache error log is different (matched with the timestamp the coredump was created):

[Fri Aug 25 05:23:42 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21435) termination signaled
[Fri Aug 25 05:23:42 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21435) terminated by calling
 exit with status '0'
[Fri Aug 25 05:23:45 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (uid 1002, gid 1002) restarted (p
id 21469)
[Fri Aug 25 05:28:42 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21469) termination signaled
[Fri Aug 25 05:28:42 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21469) terminated due to unc
aught signal '11' (RPC: Authentication error), a core file may have been generated
[Fri Aug 25 05:28:46 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (uid 1002, gid 1002) restarted (p
id 21532)
[Fri Aug 25 05:33:44 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21532) termination signaled
[Fri Aug 25 05:33:44 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (pid 21532) terminated by calling
 exit with status '0'
[Fri Aug 25 05:33:48 2006] [warn] FastCGI: (dynamic) server "/***/fcgi-bin/trac.fcgi" (uid 1002, gid 1002) restarted (p
id 21591)

(I understand the "terminated by calling exit with status '0'" behaviour is normal due to the FastCGI settings)

I don't know what the cause could have been for that to occur.

Thanks for your time!

[Christian Boos]

Any chance that you're accessing the SQLite's <tracenv>/db/trac.db file over a NFS share? (cf. ​google:"RPC+Authentication+error")

[anonymous]

Hi Christian..

No, the db file is on the same server. I don't know what the cause of that error could be.

Regards,

[Christian Boos]

Any news on this?

[Christian Boos]

Apparently not, closing.