Hi,

this is strange because the cfg framework says that the offset between cfg_group_tm.tm_auto_inv_100_r and cfg_group_tm.tm_unix_tx_timeout is 4, but I think sizeof(char *) should be 8 on 64bits, so the offset should be at least 8. (cfg.c:81)

Andrei, do you have any hint?

Nils, just to be sure, did you compile the core on the same machine with the same flags? Could you check the value of size variable before and after cfg.c:81 when i=12? And after cfg.c:72 when i=13?

Thanks, Miklos

On 05/19/2009 01:38 PM, Nils Ohlmeier wrote:

Hi Miklos,

Miklos Tirpak wrote:

...

unfortunately I do not have access to a 64 bit machine now. Could you help me with some gdb info?

sure

...

Break at cfg.c:132 when the config group "tm" is declared. Verify that

• "p &default_tm_cfg.ruri_matching" and "p &default_tm_cfg" return the

same address.

these are equal.

...

• p (char*)&default_tm_cfg.fr_inv_timeout_next -

(char*)&default_tm_cfg.ruri_matching and p mapping[30].offset return the same value.

no they dont return the same value.

...

If not, then could you check which offset is wrong with decreasing the index and checking each variable of the default_tm_cfg structure, like:

p (char*)&default_tm_cfg.reparse_on_dns_failover - (char*)&default_tm_cfg.ruri_matching p mapping[29].offset

The variable with last correct offset value is tm_auto_inv_100_r. I guess the two variables with pointers to strings are causing the problem. Please find my whole gdb output for verification below.

Thanks Nils

132 if (size != def_size) {

(gdb) p &default_tm_cfg.ruri_matching

$1 = (int *) 0x7f4c676d5860

(gdb) p &default_tm_cfg

$2 = (struct cfg_group_tm *) 0x7f4c676d5860

(gdb) p (char*)&default_tm_cfg.fr_inv_timeout_next

$3 = 0x7f4c676d58f0 "0u"

(gdb) p (char*)&default_tm_cfg.ruri_matching

$4 = 0x7f4c676d5860 "\001"

(gdb) p mapping[30].offset

$5 = 120

(gdb) p (char*)&default_tm_cfg.fr_inv_timeout_next - (char*)&default_tm_cfg.ruri_matching $6 = 144

(gdb) p &default_tm_cfg $7 = (struct cfg_group_tm *) 0x7f4c676d5860 (gdb) p default_tm_cfg $8 = {ruri_matching = 1, via1_matching = 1, fr_timeout = 30000, fr_inv_timeout = 120000, wait_timeout = 5000, delete_timeout = 200, rt_t1_timeout = 500, rt_t2_timeout = 4000, tm_max_inv_lifetime = 180000, tm_max_noninv_lifetime = 32000, noisy_ctimer = 1, tm_auto_inv_100 = 1,

tm_auto_inv_100_r = 0x7f4c674b7030 "trying -- your call is important to us", tm_unix_tx_timeout = 500, restart_fr_on_each_reply = 1, pass_provisional_replies = 0, tm_aggregate_auth = 1, unmatched_cancel = 0, default_code = 500,

default_reason = 0x7f4c674b7057 "Server Internal Error", reparse_invite = 1, ac_extra_hdrs = { s = 0x0, len = 0}, tm_blst_503 = 0, tm_blst_503_default = 0, tm_blst_503_min = 0, tm_blst_503_max = 3600, tm_blst_methods_add = 1, tm_blst_methods_lookup = 4294967287, cancel_b_flags = 1, reparse_on_dns_failover = 1, fr_inv_timeout_next = 30000} (gdb) p (char*)&default_tm_cfg.reparse_on_dns_failover - (char*)&default_tm_cfg.ruri_matching $9 = 140

(gdb) p mapping[29].offset $10 = 116 (gdb) p (char*)&default_tm_cfg.cancel_b_flags - (char*)&default_tm_cfg.ruri_matching $11 = 136

(gdb) p mapping[28].offset $12 = 112 (gdb) p (char*)&default_tm_cfg.tm_blst_methods_lookup - (char*)&default_tm_cfg.ruri_matching $13 = 132

(gdb) p mapping[27].offset $14 = 108 (gdb) p (char*)&default_tm_cfg.tm_blst_methods_add - (char*)&default_tm_cfg.ruri_matching $15 = 128

(gdb) p mapping[26].offset $16 = 104 (gdb) p (char*)&default_tm_cfg.tm_blst_503_max - (char*)&default_tm_cfg.ruri_matching $17 = 124

(gdb) p mapping[25].offset $18 = 100 (gdb) p (char*)&default_tm_cfg.tm_blst_503_min - (char*)&default_tm_cfg.ruri_matching $19 = 120

(gdb) p mapping[24].offset $20 = 96 (gdb) p (char*)&default_tm_cfg.tm_blst_503_default - (char*)&default_tm_cfg.ruri_matching $21 = 116

(gdb) p mapping[23].offset $22 = 92 (gdb) p (char*)&default_tm_cfg.tm_blst_503 - (char*)&default_tm_cfg.ruri_matching $23 = 112

(gdb) p mapping[22].offset $24 = 88 (gdb) p (char*)&default_tm_cfg.ac_extra_hdrs - (char*)&default_tm_cfg.ruri_matching $25 = 96 (gdb) p mapping[21].offset $26 = 84 (gdb) p (char*)&default_tm_cfg.reparse_invite - (char*)&default_tm_cfg.ruri_matching $27 = 88 (gdb) p mapping[20].offset $28 = 80 (gdb) p (char*)&default_tm_cfg.default_reason - (char*)&default_tm_cfg.ruri_matching $29 = 80 (gdb) p mapping[19].offset $30 = 76 (gdb) p (char*)&default_tm_cfg.default_code - (char*)&default_tm_cfg.ruri_matching $31 = 76 (gdb) p mapping[18].offset $32 = 72 (gdb) p (char*)&default_tm_cfg.unmatched_cancel - (char*)&default_tm_cfg.ruri_matching $33 = 72 (gdb) p mapping[17].offset $34 = 68 (gdb) p (char*)&default_tm_cfg.tm_aggregate_auth - (char*)&default_tm_cfg.ruri_matching $35 = 68 (gdb) p mapping[16].offset $36 = 64 (gdb) p (char*)&default_tm_cfg.pass_provisional_replies - (char*)&default_tm_cfg.ruri_matching $37 = 64 (gdb) p mapping[15].offset $38 = 60 (gdb) p (char*)&default_tm_cfg.restart_fr_on_each_reply - (char*)&default_tm_cfg.ruri_matching $39 = 60 (gdb) p mapping[14].offset $40 = 56 (gdb) p (char*)&default_tm_cfg.tm_unix_tx_timeout - (char*)&default_tm_cfg.ruri_matching $41 = 56 (gdb) p mapping[13].offset $42 = 52 (gdb) p (char*)&default_tm_cfg.tm_auto_inv_100_r - (char*)&default_tm_cfg.ruri_matching $43 = 48 (gdb) p mapping[12].offset $44 = 48

...

Thanks, Miklos

On 05/19/2009 02:24 AM, Nils Ohlmeier wrote:

...

Hello,

when I try to start SER with the ser-basic.cfg it fails with the following error message:

0(13147) ERROR: <core> [cfg/cfg.c:135]: ERROR: register_cfg_def(): the specified size (152) of the config structure does not equal with the calculated size (148), check whether the variable types are correctly defined!

Note: I added the size informations to this error message just a minute ago so that the error message is hopefully more meaningful.

Does anybody know what is wrong here? I'm using Gentoo Linux with 64bit, maybe that is the reason for this failure?!

Thanks Nils

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hi,

thanks a lot Andrei!

Nils, you can easily verify that the offsets work with setting the value of unix_tx_timeout over RPC and verifying it directly with gdb:

sercmd cfg.set_now_int tm unix_tx_timeout 600

(gdb) p ((struct cfg_group_tm *)tm_cfg)->tm_unix_tx_timeout $3 = 600

(I have attached to the ctl process because it refreshes its configuration after the sercmd command. Otherwise you need to send a SIP message to let the listeners update their config pointers.)

Thanks, Miklos

On 05/22/2009 01:15 PM, Andrei Pelinescu-Onciul wrote:

On May 21, 2009 at 18:20, Miklos Tirpak miklos@iptel.org wrote:

...

Hi,

this is strange because the cfg framework says that the offset between cfg_group_tm.tm_auto_inv_100_r and cfg_group_tm.tm_unix_tx_timeout is 4, but I think sizeof(char *) should be 8 on 64bits, so the offset should be at least 8. (cfg.c:81)

Yes, it should be 8.

...

Andrei, do you have any hint?

I've looked at it on a 64 bits system and I found a problem: the sanity check compares the computed size directly with sizeof(struct). However the structure will be padded if its size is not a multiple of the size of the type of its member requiring the highest alignment. In our case the extra char* member on 64 bits caused a 4 bytes padding and the sanity check failed. I've already commited the fix to the repository.

Nils gbd output looks very strange, but hopefully we won't need to investigate further.

Andrei

[...]