64 bit Firebird 2.5, and Solaris Sparc

Looks like the job is already done... I read the following post on Firebird Development from Bill Oliver (SAS)

"I confirm that the issues are fixed in HEAD. I confirmed this on 64-bit
Solaris Sparc, built with the Sun Studio native compiler - using pthreads!!!

"How cool is that! Thanks very much guys for the quick turn-around.

Also, big thanks to Alex for his assitance with this port!!"

Excellent work!

GCC 4.01 MacOSX & Weak Symbols

During the QA process for Firebird V2.1.2 we found that there was a problem with creating a database remotely. In effect the inet server would crash.

On further analysis we found that we have a problem where the function free()(standard C dynamic memory deallocator) was being invoked with the incorrect parameter, an address which had not been allocated using malloc().

After setting up the code to make the inet server call abort we got the following stack trace

(fragment)

#0 0x90005efc in free ()
#1 0x010440b8 in Firebird::AbstractString::~AbstractString (this=0xbfffcb04)
at ../src/include/../common/classes/fb_string.h:375
#2 0x010440f8 Firebird::StringBase::~StringBase
(this=0xbfffcb04) at ../src/include/../common/classes/fb_string.h:391
#3 0x0101593c in LD_setup_attributes (textTypeName=0xbfffcd60 "ES_ES",
charSetName=0xbfffccdc "ISO8859_1",
configInfo=0x6a1204 "filename=$(this)/fbintl;icu_versions=default",
srcLen=39, src=0x69a898 "DISABLE-COMPRESSIONS=1;SPECIALS-FIRST=1",
dstLen=512, dst=0xbfffcdb8 "DISABLE-COMPRESSIONS=1;SPECIALS-FIRST=1,")
at ../src/intl/ld.cpp:457
#4 0x3011b1b4 in Jrd::IntlManager::setupCollationAttributes
(collationName=@0xbfffd0e4, charSetName=@0xbfffd0b8,
specificAttributes=@0xbfffd14c, newSpecificAttributes=@0xbfffd178)
at ../src/jrd/IntlManager.cpp:317

From this back trace you can see that free() is called from the operator delete[], where we would have expected MemoryPool::deallocate() to be used. For some
reason the default operator delete[] is used.

Strange, how did this code arrive at address 0x010440b8?

After an analysis of nm output for fbintl and the linker's map of symbols Alex found that at this address is in fact located the redefined operator delete[], which was compiled in via ld.cpp. However in the assembly version of the file (ld.cpp), it was correctly redefined (i.e. it was calling MemoryPool::deallocate()) operator delete[].

Houston it looks as if we have a buggy toolchain.

But we also need to take into account that AbstractString dtor() and operator delete[] are also WEAK symbols. Weak meaning that such symbols may be present in many object files, and the linker at link-time will take it from the relevant one. But in this case it looks as if it was taken from another file...

But after we compiled into assembler all of the files that are used in the fbintl
library we found that they all contained the correctly redefined operator
delete[]. As such there is no use of operator delete[], calling std free() function in our code, but anyway we get such use in the resulting binary.

In effect it looks like weak symbols are broken on MacOSX GCC 4.01 (Apple build 5747). And the only way to fix a problem is to avoid them.

We are currently compiling Firebird on PPC 10.4 (Tiger) using a new switch -fno-weak

fno-weak:
"Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits."

MallocLogFile, MacOSX & LaunchDaemons

I have been debugging the fb_inet_server trying to find a problem in Firebird 2.1.2 Classic for PowerPC. That takes a little bit of setting up, but I will try and explain that in another blog post. Part of one of the things that I wanted to check was what malloc was doing. However by default any "error" messages get sent to standard out, however you can set the environment variable MallocLogFile to capture messages to a specified file. But setting that in my normal environment is going to work because the fb_inet_server is actually launched by the LaunchDaemon and is then also forked. So we need to set the environment variable in the LaunchDaemon script directly.

The solution:

You need to edit the xml script that "launches" the fb_inet_server. This file can be found in /Library/LaunchDaemons and is called org.firebird.gds.plist

First of all unload the current launch definition

launchctl unload /Library/LaunchDaemons/org.firebird.gds.plist

Then edit the file as follows
After

<string>org.firebird.gds</string>

Add

<Key>EnvironmentVariables</Key>
<dict>
<Key>MallocLogFile</Key>
<String>/Library/Frameworks/Firebird.framework/Malloc.log</String>
</dict>

Save and

launchctl load /Library/LaunchDaemons/org.firebird.gds.plist

Modern Music

The Brits - Hmmm - Not my list of recommended music....
Try listening to:

1. The Killers (excellent)
2. Editors (good)
3. The View (acquired taste)

Enjoy

Bosmere Products Ltd

I don't normally do this, but about a month ago I sent the following letter to a company in the UK. I am still waiting for a reply. I am not expecting to receive one, nor do I expect a refund.

So if anybody out there is googling for Patio Set Covers, and happens to bump into this post...

We had bought a patio set cover for our patio tables and chairs in November 2008, and covered them up using this cover. By February 2009, the cover was falling apart.
Letter follows.

Customer Services
Bosmere Products Ltd,
Unit 5 Mitchell Way,
Airport Service Road,
Portsmouth,
PO3 5PR,
England.

Dear Sir,

I am writing to express my disappointment with the quality of your 6 seater circular patio set cover.

I purchased this cover from Chinnor Garden Centre, Chinnor, Oxfordshire for £39.99 on 4th November 2008 while on a short trip to the UK from my home in France.

Within a week the first of the supposedly heavy duty ties had broken – followed by the other 3 within the next month. Attempts to re-tie the broken cords were useless (they simply snapped again) and now the metal eyelets have ripped away from the plastic cover, now making it impossible to secure the cover even with heavy duty polypropylene rope which I purchased.

On removing the cover, it is also apparent that large areas of the plastic coating on the inside of the cover have completely worn away and it is no longer waterproof.
We do not live in the Outer Hebrides but south of the Loire valley in France, therefore it has most certainly not been exposed to unusually severe weather here!
It is clear that this product is not fit for purpose – it is marketed as being top quality PVC backed polyester, secure in windy conditions and giving full winter protection – it is obvious that after just two and a half months use that it is none of these.

As we live in France and very seldom travel to the UK we are unable to return the cover to the place where we purchased it. I would ask you therefore to refund the cost of the cover.

Yours faithfully
Mr Paul Beach.

Daily Telegraph Cryptic No 25851

I am a great fan of the Daily Telegraph Cryptic crossword, and have been doing, or attempting to do this crossword, just about every day since I was a student at University.

I was introduced to it by my Grandmother many years ago, when stayed with her in Banbury.

"We" (and I use We, advisedly) used to do the crossword when we had breakfast, usually my Grandmother doing the crossword and explaining how things worked, whilst every now and then I would have a eureka moment. Anyway enough digression.

I found the following web site that specialises in helping people through the Telegraph Cryptic crossword in a way that is much more friendly than normal "specialist" cryptic sites.

Big Dave's Telegraph Crossword Blog

For those of you who don't know Libellule, is french for Dragonfly.

Memory Utilisation by the Firebird Classic Server

The following was posted by Dimitry Yemanov on the Firebird Development list in response to some questions about Memory Usage within Firebird (Classic)

"Need some help understanding how memory allocation is done per process on Linux 1.5.5 CS. It's understandable that there is some amount of working memory needed to support fb process, plus per connection amount, plus cache depending on database page size and buffer count."

Per process (independent) memory usage:
- page buffers (40MB in your case)
- metadata cache (cannot be predicted/controlled, depends on the schema complexity, especially number of interdependent PSQL objects)
- sort buffers (turned off by default on Classic, see SortMemUpperLimit in firebird.conf)
- undo log (cannot be predicted/controlled, wastes memory mostly for multiple batch updates in the same transaction)

Shared memory usage (depends on other connections):
- lock table (starts with LockMemSize and auto-growing)
- event table (starts with EventMemSize and auto-growing)

"What makes me wander is how concurrent user connection count affects memory utilization per process. Somehow the more users we have on the server - the bigger overhead is added per connection. When comparing mem utilization on same database having single connection and 55 for example - utilized memory delta increases by ~33MB. On server having 160 connections it's almost 2-3 times more. Is this lock manager related data? 30MB just for that?"

The lock manager data is shared, but it's mapped into the address space of the every Classic process. I dunno whether the Linux tools include the mmap'ed memory into the counters you check or not. If so, it gets easy to explain: yes, this increase is caused by the lock table. You can draftly calculate the lock manager memory requirements by this formula:

number of connections * number of page buffers * 100 bytes.

The exact size could be found in the output of fb_lock_print (header section) at runtime. With your quite large (for Classic) page cache settings, the numbers should be nearly the same as you experience.