Dear all,

Apologies for the earlier confusion—my toolchain was misconfigured, and I mistakenly compiled the unpatched BIRD sources. Upon correcting this, I believe the first patch already addresses the issue. However, I noticed that the two patches result in different alignments. Below is a summary of the observed alignments:

*No Patch:*
|ALIGN: 8 4 4 4 8|

*First Patch (fix-net-addr-alignment.patch):*
|ALIGN: 2 4 4 4 4|

*Last Patch (net-addr-u32-align.patch):*
|ALIGN: 4 4 4 4 4|

Bests,
Nick

On 12/12/24 2:31 AM, Ondrej Zajicek wrote:
On Thu, Dec 12, 2024 at 12:50:31AM +0100, nick wrote:
Can you give me a quick guide on how to enable the debug output?
I tried for example setting in the config file:

log "/tmp/birddebug.log" all;
debug protocols all;
I am not able to see any output from ALIGN.
As the log message is generated even before the config file is parsed, it
uses the default log output, which is stderr and syslog (if available):

# ./bird -l
bird: ALIGN: 4 4 4 8 8

# grep ALIGN /var/log/syslog
2024-12-12T02:11:59.513900+01:00 feanor bird: ALIGN: 4 4 4 8 8

(also, you could use option -D <debugfile>, in which case the default log
output would be directed there.)


Alternatively, if logging to the usual configured logfile would be more
practical to you, the test call could be moved from bgp_build() to
bgp_init() (attached log-alignment-v2.patch), which is called after
everything is initialized and log is directed to the configured file.



On 12/11/24 4:40 AM, Ondrej Zajicek wrote:
On Wed, Dec 11, 2024 at 02:14:39AM +0100, nick wrote:
Thank you! I just ran a quick test and encountered the same crash at the
same line. I’ll have more time to investigate tomorrow and can provide
additional details then. Do you have any other ideas I could try in the
meantime?
A part of my previous explanation was wrong, the issue is not related to
net_copy(), as the crash happened even before.

For some reason, struct bgp_prefix is u64-aligned. That makes sense in
the original code, where u64 alignment is forced by struct net_addr, but
i have no idea why this is true even after the patch removing the forced
alignment.

The slab allocator in sl_alloc() just returns u32-aligned memory, because
it is configured for sizeof(struct bgp_prefix) + sizeof(net_addr_ip6) and
the second is 20 as net_addr_ip6 is u32-aligned. The sl_alloc() internally
only enforces word-size alignment, wich is u32 in your case.

Please disregard the previous patch. Can you try the first attached patch
(log-alignment.patch) to log alignment of different structures with or
without the second patch (net-addr-u32-align.patch) and report me results?

Reply via email to