[mapguide-commits] r10028 - trunk/MgDev/Oem/agg-2.4/include

svn_mapguide at osgeo.org svn_mapguide at osgeo.org
Mon Feb 13 02:07:25 PST 2023


Author: jng
Date: 2023-02-13 02:07:24 -0800 (Mon, 13 Feb 2023)
New Revision: 10028

Modified:
   trunk/MgDev/Oem/agg-2.4/include/agg_font_cache_manager.h
Log:
A commentary update on the saga of #2570

No actual code changes.

Modified: trunk/MgDev/Oem/agg-2.4/include/agg_font_cache_manager.h
===================================================================
--- trunk/MgDev/Oem/agg-2.4/include/agg_font_cache_manager.h	2023-02-09 11:58:27 UTC (rev 10027)
+++ trunk/MgDev/Oem/agg-2.4/include/agg_font_cache_manager.h	2023-02-13 10:07:24 UTC (rev 10028)
@@ -172,6 +172,37 @@
                 if(m_num_fonts >= m_max_fonts)
                 {
                     obj_allocator<font_cache>::deallocate(m_fonts[0]);
+                    /*
+                    UPDATE 13/02/2023:
+
+                    Way back in r8844 (30/11/2015) we changed this call from memcpy to memmove 
+                    without a real explanation as to why (other than: So this code no longer segfaults
+                    on Ubuntu 14.04 at the time)
+
+                    With this update, we now have a proper explanation.
+
+                    In glibc 2.14, an optimization was added to memcpy that makes it faster, but will
+                    no longer work with overlapping memory ranges.
+
+                    Our previous Ubuntu target before discovery of this issue and applying the subsequent
+                    fix in r8844 was 12.04 LTS which shipped with glibc 2.13 (that pre-dates this 
+                    behavior change)
+
+                    Ubuntu 14.04 shipped with glibc 2.19 (that has this memcpy behavior change), causing
+                    this new segfaulting behavior due to the default linking policy of always choosing the latest
+                    version of any given libc symbol.
+
+                    The change to memmove was because at that time we didn't know of a possible alternative
+                    solution: To explictly use the version of memcpy introduced in glibc 2.2.5 (ie. memcpy at GLIBC_2.2.5)
+                    through the use of .symver asm directive
+
+                    However, what's done is done and there's no point changing back because things work just
+                    fine with memmove. This big wall of text is just to explain why the change from memcpy
+                    to memmove was made.
+
+                    Ref that sparked this commentary:
+                    https://blog.gibson.sh/2017/11/26/creating-portable-linux-binaries/#example-glibc-s-memcpy
+                    */
                     memmove(m_fonts, 
                             m_fonts + 1, 
                            (m_max_fonts - 1) * sizeof(font_cache*));



More information about the mapguide-commits mailing list