Issue Details (XML | Word | Printable)

Key: CORE-5517
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Christian Pradelli
Votes: 0
Watchers: 4

If you were logged in you would be able to see more operations.
Firebird Core

Classic server periodically raise "Global mapping memory overflow" and need to be restarted to accept new connections

Created: 10/Apr/17 04:05 PM   Updated: 14/May/17 01:35 PM
Component/s: Engine
Affects Version/s: 4.0 Initial, 3.0.0, 3.0.1, 3.0.2
Fix Version/s: 4.0 Alpha 1, 3.0.3

File Attachments: 1. Text File 5517.patch (0.5 kB)

Environment: Ubuntu 16.04 64 bits, 4 cores, 32gb ram

QA Status: Not enough information
Test Details: Need any suggestion about possible test implementation for this ticket.
Test Specifics: Architecture (SS/CS) specific, Platform (Windows/Linux) specific

 Description  « Hide
I have a server in production.

Firebird Classical server
Ubuntu 16.04 64 bits
4 cores
32gb ram

It is serving 30 databases with 2~5 connections each one.
Every 4 to 5 days new client connections raise the error "Global mapping memory overflow" and the server needs to be completely rebooted to continue working.

The problem started when we switch from SupersServer to Classical Server.

The only place where I found the text error in source code is in /src/jrd/mapping.cpp

if (process >= sMem->processes)
if (((U_IPTR) &sMem->process[sMem->processes]) - ((U_IPTR) sMem) > DEFAULT_SIZE)
(Arg::Gds(isc_random) << "Global mapping memory overflow").raise();

Which could be the problem?

Does any firebird.conf parameter affect this issue?


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 10/Apr/17 06:12 PM
This is really a support question, please post this to the Firebird Support mailing list.

Christian Pradelli added a comment - 10/Apr/17 06:45 PM
Hi Sean,

I understand that my last question sound as a support question but I only asked it to do more tests and provide more information about this issue.
We use classical server since first Firebird version and we never saw this issue.

Checking the code I also not found parameters directly related with the conditional that raise the exception.
DEFAULT_SIZE is a hard-coded constant, so at first look it sound as a kind of leak.
it seems that sMem->processes is constantly incremented and never decremented.

Alexander Peshkov added a comment - 11/Apr/17 01:09 PM
Christian, can you try with a 5517.patch attached?

Christian Pradelli added a comment - 11/Apr/17 04:01 PM
Yes, I do it right now.

The server is under heavy load, so I need to replace Firebird very fast.
It's safe to only replace the binaries (/firebird/bin) with the compiled ones, instead of uninstall and install?
if yes, which binaries should I replace all "/bin" or only "/bin/firebird" executable?

Alexander Peshkov added a comment - 11/Apr/17 04:08 PM - edited
It's enough to replace plugins/ (provided you use same gcc version).
If gcc version is changed (or you use currently firebird compiled at some other place) - better replace all binaries.
You need not stop all firebird processes to do it - just stop xinetd, replace file and start xinetd again.
It does not mean that such trick can be done in any case - only for _this_ change it's OK.

Christian Pradelli added a comment - 11/Apr/17 08:57 PM
Thank you.
I putted it on production, I need to test it at least one week to see if the patch works.

Christian Pradelli added a comment - 26/Apr/17 07:09 PM
It's running since 11/Apr with no issues.
if no issue apears next week I think we can considered it fixed.

Christian Pradelli added a comment - 10/May/17 10:27 AM
Hi Alexandre,

This seems to be fixed, are you going to include patch in next release?