Re: svn commit: r1884103 - in /apr/apr/branches/1.7.x: ./ include/arch/beos/ include/arch/netware/ include/arch/unix/ include/arch/win32/ memory/unix/ threadproc/beos/ threadproc/netware/ threadproc/o
On Wed, Jun 29, 2022 at 4:47 PM William A Rowe Jr wrote: > > This change does introduce an API change, and a somewhat possibly dangerous > structure size alteration, and seems to be out of bounds for apr 1.7.x branch. AFAICT, this change only touches internal/opaque structures.. Are you talking about apr__pool_unmanage()? If so it was later removed in r1897210. About this change particularly, it fixes serious bugs in APR threads, just run the tests with r1884102 (before this commit), APR_POOL_DEBUG (to ease reproduction) and under ASan (Address Sanitizer, -fsanitize=address), or maybe it was httpd's tests. I can't remember the details and travis does not seem to keep builds history that far (Dec 2020) so I can't point you to the stack traces / reports. I do remember that period where we started to run ASan builds though (in httpd and later APR), this led to a series of fixes in APR, including this one.. > > Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may > experience > unintended side-effects. Anyone running apr-1.7.x without these fixes and using threads is kind of in UB land. > > While it's true that include/arch and include/private are not > considered generally > supported, folks are known to use them, and macros may cause the library to > bleed internals. Really? We don't install these headers, and they are opaque precisely so that we can change them without breaking users. If users copy private headers for their use cases, shouldn't they take the burden of maintaining their codebase (depending on that) when those headers change? This can't be on us.. By making such impracticable policies for revision changes (semver sense), we are going to simply not fix anything but trivial changes without bumping minor, and no one would/should care about the old (though still "maintained") minor versions. What's the point of releasing 1.7.1 then? Let's go with 1.8.0 only, simpler (less maintenance) and better for everybody.. Regards; Yann.
Re: svn commit: r1863234 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c
Thanks! Am 29.06.2022 um 17:01 schrieb Yann Ylavic: On Wed, Jun 29, 2022 at 4:41 PM William A Rowe Jr wrote: This is the first commit which appeared to break APR in such a way that code compiled against apr 1.7.1 would be unable to run against apr 1.7.0 binaries. I think it has been reverted already by http://svn.apache.org/r1902022 Regards; Yann.
Re: svn commit: r1863234 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c
Thanks, I will revert. Am 29.06.2022 um 16:40 schrieb William A Rowe Jr: This is the first commit which appeared to break APR in such a way that code compiled against apr 1.7.1 would be unable to run against apr 1.7.0 binaries. Thoughts, rjung? Are you willing to revert? This would persist on apr 1.8.x for those interested in this new feature. On Wed, Jul 17, 2019 at 2:04 PM wrote: Author: rjung Date: Wed Jul 17 19:04:43 2019 New Revision: 1863234 URL: http://svn.apache.org/viewvc?rev=1863234=rev Log: Add empty stubs for APR pool functions, that are only needed when APR_POOL_DEBUG is defined, but can be aor should be called from app code. Providing stubs allows the app code to stay the same when running with or without debugging APR lib (no need for app recompilation). Backport of r1863217 from trunk. Modified: apr/apr/branches/1.7.x/ (props changed) apr/apr/branches/1.7.x/include/apr_pools.h apr/apr/branches/1.7.x/memory/unix/apr_pools.c Propchange: apr/apr/branches/1.7.x/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jul 17 19:04:43 2019 @@ -1,4 +1,4 @@ /apr/apr/branches/1.4.x:1003369,1101301 -/apr/apr/trunk:733052,739635,741862,741866-741867,741869,741871,745763-745764,746310,747990,748080,748361,748371,748565,74,748902,748988,749810,760443,767895,775683,782838,783398,783958,784633,784773,788588,789050,793192-793193,794118,794485,795267,799497,800627,809745,809854,810472,811455,813063,821306,829490,831641,832904,835607,888669,892028,892159,892435,892909,896382,896653,899905,901088,902077,902090,908427,910419,910597,917819,917837-917838,923311,923320,925965,929796,930508,931973,932585,951771,960665,960671,979891,983618,989450,990435,1003338,100,107,1055657,1072165,1078845,1081462,1081495,1082177,1083038,1083242,1084662,1086695,1088023,1089031,1089129,1089438,1099348,1103310,1183683,1183685-1183686,1183688,1183693,1183698,1213382,1235047,1236970,1237078,1237507,1240472,1340286,1340288,1340470,1341193,1341196,1343233,1343243,1367050,1368819,1370494,1372018,1372022,1372093,1372849,1376957,1384764,1389077,1400200,1402868,1405985,1406690,1420106,1420109,1425356,142 8809,1438940,1438957-1438959,1442903,1449568,1456418,1459994,1460179-1460180,1460184,1460241,1460399,1460405,1462738,1462813,1470186,1470348,1475509,1478905,1480067,1481186,1481262,1481265,1484271,1487796,1489517,1496407,1502804,1510354,1516261,1523384,1523479,1523484,1523505,1523521,1523604,1523613,1523615,1523844-1523845,1523853,1524014,1524031,1528797,1528809,1529488,1529495,1529515,1529521,1529668,1530786,1530800,1530988,1531554,1531768,1531884,1532022,1533104,1533111,1533979,1534882,1535027,1535157,1536744,1538171,1539374,1539389,1539455,1539603,1541054,1541061,1541486,1541655,1541666,1541744,1542601,1542779,1543033,1543056,1548575,1550907,1551650,1551659,1558905,1559382,1559873,1559975,1561040,1561260,1561265,1561321,1561347,1561356,1561361,1561394,1561555,1571894,1575509,1578420,1587045,1587063,1587543,1587545,1588878,1588937,1589982,1593611,1593614-1593615,1593680,1594684,1594708,1595549,1597797,1597803,1604590,1604596,1604598,1605104,1610854,1611023,1611107,160,167, 1611120,1611125,1611184,1611193,1611466,1611515,1611517,1625173,1626564,1634615,1642159,1648830,1664406,1664447,1664451,1664471,1664769-1664770,1664775,1664904,1664911,1664958,1666341,1666411,1666458,111,1667420-1667421,1667423,1667900-1667901,1667903,1667914-1667916,1667962,1669077,1671292,1671329,1671356,1671386,1671389,1671513-1671514,1671957,1672354,1672366,1672495,1672575,1674566,1675644,1675656,1675668,1675967,1675970,1675982,1676013,1683521,1685929,1696140,1696767,1722547,1722557,1726928,1727020,1727160,1727175,1727199,1728957,1732582,1733451,1733594,1733694,1733706,1733708,1733775,1734816,1736552,1738791,1738925,1750374,1755709,1755740,1755746,1755758,1755954,1761279,1762326,1774712,1774973,1775069,1776994,1776998,1788334,1788337,1788929,1789947,1789998,1790045,1790200,1790296,1790302-1790304,1790330-1790331,1790436,1790439,1790444,1790446,1790488,1790521,1790523,1790569,1790632,1791598,1791718,1791728,1792620-1792622,1792625,1792961,1792963,1794266,1797415,1798105,18053 80,1808039,1808836,1808910,1809649,1810452,1813286,1813330,1814239-1814240,1814326,1814329,1814331,1816527,1816628,1817485,1819857-1819858,1819860-1819861,1819934-1819935,1820080,1820755,1822357,1827534,1832203,1832691,1832985,1834253,1834494,1834541,1836235,1839068,1839493,1839622,1839769,1840372,1841078,1846806,1850087,1850095,1851541-1851542,1854123,1855049,1855347,1855443-1855444,1855839-1855840,1855855,1855864,1855867,1855877,1855949,1856022,1856042-1856043,1856046,1856050,1856063,1856089,1856096,1856178,1856192,1856196,1856756,1858596,1863205
Re: svn commit: r1863234 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c
On Wed, Jun 29, 2022 at 4:41 PM William A Rowe Jr wrote: > > This is the first commit which appeared to break APR in such a way > that code compiled > against apr 1.7.1 would be unable to run against apr 1.7.0 binaries. I think it has been reverted already by http://svn.apache.org/r1902022 Regards; Yann.
Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c
This change does introduce an API change, and a somewhat possibly dangerous
structure size alteration, and seems to be out of bounds for apr 1.7.x
branch, as
identified in the commit message.
Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may
experience
unintended side-effects. The eventual change still is present for apr
1.8 adopters.
Thoughts? ylavic are you willing to revert?
On Thu, Mar 11, 2021 at 10:21 AM wrote:
>
> Author: ylavic
> Date: Thu Mar 11 16:21:07 2021
> New Revision: 1887497
>
> URL: http://svn.apache.org/viewvc?rev=1887497=rev
> Log:
> Merge r1887060 from trunk:
>
> Align apr_mmap()ing offset to a page boundary. PR 65158.
>
> This is requirement for unix systems, and otherwise can cause failures or
> undefined behaviour with some filesystems.
>
> Add apr_mmap_t->poffset on unixes to track the offset to the previous page,
> relative to the user requested/actual offset. This allows ->mm and ->size to
> still point to the actual data, while munmap() now deletes the full range
> from the start of the page.
>
> Tests updated accordingly.
>
>
> * Changes between r1887060 and this 1.7.x backport
>
> Since the layout of struct apr_mmap_t cannot change (non opaque), the poffset
> is over-allocated in mmap/unix/mmap.cmmap.c which uses this layout internally:
> struct mm_layout {
> apr_mmap_t mm;
> apr_off_t poffset;
> };
>
> This works for all the apr_mmap_t created by apr_mmap_create() with which any
> apr_mmap_*() function can then be called.
>
> If a user creates an apr_mmap_t "by hand", with this change it cannot be
> passed
> to apr_mmap_dup() without causing an out-of-bound read. This is hardly a new
> limitation though, the refcounting which is the point of apr_mmap_dup() and
> apr_mmap_delete() comes from the private function mmap_cleanup() anyway, so
> there is no point in using these two functions with hand made apr_mmap_t (if
> there ever was a point in the first place to create an hand made
> apr_mmap_t..).
>
>
> Submitted by: ylavic
>
> Added:
> apr/apr/branches/1.7.x/test/data/mmap_large_datafile.txt
> - copied unchanged from r1887060,
> apr/apr/trunk/test/data/mmap_large_datafile.txt
> Modified:
> apr/apr/branches/1.7.x/ (props changed)
> apr/apr/branches/1.7.x/CHANGES
> apr/apr/branches/1.7.x/mmap/unix/mmap.c
> apr/apr/branches/1.7.x/test/testfnmatch.c
> apr/apr/branches/1.7.x/test/testmmap.c
>
> Propchange: apr/apr/branches/1.7.x/
> --
> Merged /apr/apr/trunk:r1887060
>
> Modified: apr/apr/branches/1.7.x/CHANGES
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/CHANGES?rev=1887497=1887496=1887497=diff
> ==
> --- apr/apr/branches/1.7.x/CHANGES [utf-8] (original)
> +++ apr/apr/branches/1.7.x/CHANGES [utf-8] Thu Mar 11 16:21:07 2021
> @@ -1,6 +1,8 @@
> -*- coding: utf-8 -*-
> Changes for APR 1.7.1
>
> + *) Align apr_mmap()ing offset to a page boundary. PR 65158. [Yann Ylavic]
> +
>*) Don't silently set APR_FOPEN_NOCLEANUP for apr_file_mktemp() created
> file
> to avoid a fd and inode leak when/if later passed to
> apr_file_setaside().
> [Yann Ylavic]
>
> Modified: apr/apr/branches/1.7.x/mmap/unix/mmap.c
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/mmap/unix/mmap.c?rev=1887497=1887496=1887497=diff
> ==
> --- apr/apr/branches/1.7.x/mmap/unix/mmap.c (original)
> +++ apr/apr/branches/1.7.x/mmap/unix/mmap.c Thu Mar 11 16:21:07 2021
> @@ -14,6 +14,8 @@
> * limitations under the License.
> */
>
> +#include
> +
> #include "apr.h"
> #include "apr_private.h"
> #include "apr_general.h"
> @@ -33,6 +35,9 @@
> #if APR_HAVE_STDIO_H
> #include
> #endif
> +#if APR_HAVE_UNISTD_H
> +#include /* for sysconf() */
> +#endif
> #ifdef HAVE_SYS_STAT_H
> #include
> #endif
> @@ -42,6 +47,34 @@
>
> #if APR_HAS_MMAP || defined(BEOS)
>
> +#ifndef BEOS
> +struct mm_layout {
> +apr_mmap_t mm;
> +apr_off_t poffset;
> +};
> +
> +static APR_INLINE
> +apr_mmap_t *alloc_with_poffset(apr_pool_t *p)
> +{
> +struct mm_layout *layout = apr_pcalloc(p, sizeof(*layout));
> +return >mm;
> +}
> +
> +static APR_INLINE
> +void set_poffset(apr_mmap_t *mm, apr_off_t poffset)
> +{
> +struct mm_layout *layout = (struct mm_layout *)mm;
> +layout->poffset = poffset;
> +}
> +
> +static APR_INLINE
> +apr_off_t get_poffset(apr_mmap_t *mm)
> +{
> +struct mm_layout *layout = (struct mm_layout *)mm;
> +return layout->poffset;
> +}
> +#endif
> +
> static apr_status_t mmap_cleanup(void *themmap)
> {
> apr_mmap_t *mm = themmap;
> @@ -61,7 +94,7 @@ static apr_status_t mmap_cleanup(void *t
> #ifdef BEOS
> rv = delete_area(mm->area);
> #else
> -rv = munmap(mm->mm,
Re: svn commit: r1884103 - in /apr/apr/branches/1.7.x: ./ include/arch/beos/ include/arch/netware/ include/arch/unix/ include/arch/win32/ memory/unix/ threadproc/beos/ threadproc/netware/ threadproc/o
This change does introduce an API change, and a somewhat possibly dangerous
structure size alteration, and seems to be out of bounds for apr 1.7.x branch.
Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may
experience
unintended side-effects. The eventual change still is present for apr
1.8 adopters.
While it's true that include/arch and include/private are not
considered generally
supported, folks are known to use them, and macros may cause the library to
bleed internals.
On Fri, Dec 4, 2020 at 12:15 PM wrote:
>
> Author: ylavic
> Date: Fri Dec 4 18:15:55 2020
> New Revision: 1884103
>
> URL: http://svn.apache.org/viewvc?rev=1884103=rev
> Log:
> Merge r936323, r1460182, r1884077, r1884078 from trunk:
>
> OS/2: Clean up a thread's pool when it terminates.
>
>
>
> Add apr_pool_owner_set function to allow use of pool debugging with threads
>
> Actually this function has been mentioned in the docs for over 10 years
> but has never been implemented.
>
>
> Also consistently destroy the thread's pool when it exits normally, not only
> on apr_thread_exit(). This was already done on OS2.
>
> Other platforms than unix are untested.
>
>
> apr_thread: destroy the thread's pool at _join() time, unless _detach()ed.
>
> Destroying a joinable thread pool from apr_thread_exit() or when the thread
> function returns, i.e. from inside the thread itself, is racy or deadlocky
> with APR_POOL_DEBUG, with the parent pool being destroyed.
>
> This commit adds a ->detached flag in each arch's apr_thread_t struct to track
> whether a thread is detached (either at _create() or _detach() time). If
> detached, the pool is destroyed when the thread exits, otherwise when the
> thread is joined with apr_thread_join().
>
>
> apr_thread: use unmanaged pools for detached threads.
>
> A detached thread is by definition out of control, unjoinable, unmanaged,
> and it can terminate/exit after its parent pool is detroyed.
>
> To avoid use-after-free in this case, let's use an unmanaged pool for detached
> threads, either by creating an unmanaged pool from the start if the thread
> is created detached, or by "unmanaging" the pool if the thread is detached
> later with apr_thread_detach().
>
> To "umanage" the pool, provide a new internal helper, apr__pool_unmanage()
> which takes care of removing the pool from its parent's list.
>
>
> Submitted by: bjh, sf, ylavic, ylavic
>
> Modified:
> apr/apr/branches/1.7.x/ (props changed)
> apr/apr/branches/1.7.x/include/arch/beos/apr_arch_threadproc.h
> apr/apr/branches/1.7.x/include/arch/netware/apr_arch_threadproc.h
> apr/apr/branches/1.7.x/include/arch/unix/apr_arch_threadproc.h
> apr/apr/branches/1.7.x/include/arch/win32/apr_arch_threadproc.h
> apr/apr/branches/1.7.x/memory/unix/apr_pools.c
> apr/apr/branches/1.7.x/threadproc/beos/thread.c
> apr/apr/branches/1.7.x/threadproc/netware/thread.c
> apr/apr/branches/1.7.x/threadproc/os2/thread.c
> apr/apr/branches/1.7.x/threadproc/unix/thread.c
> apr/apr/branches/1.7.x/threadproc/win32/thread.c
>
> Propchange: apr/apr/branches/1.7.x/
> --
> Merged /apr/apr/trunk:r936323,1460182,1884077-1884078
>
> Modified: apr/apr/branches/1.7.x/include/arch/beos/apr_arch_threadproc.h
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/include/arch/beos/apr_arch_threadproc.h?rev=1884103=1884102=1884103=diff
> ==
> --- apr/apr/branches/1.7.x/include/arch/beos/apr_arch_threadproc.h (original)
> +++ apr/apr/branches/1.7.x/include/arch/beos/apr_arch_threadproc.h Fri Dec 4
> 18:15:55 2020
> @@ -45,6 +45,7 @@ struct apr_thread_t {
> void *data;
> apr_thread_start_t func;
> apr_status_t exitval;
> +int detached;
> };
>
> struct apr_threadattr_t {
>
> Modified: apr/apr/branches/1.7.x/include/arch/netware/apr_arch_threadproc.h
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/include/arch/netware/apr_arch_threadproc.h?rev=1884103=1884102=1884103=diff
> ==
> --- apr/apr/branches/1.7.x/include/arch/netware/apr_arch_threadproc.h
> (original)
> +++ apr/apr/branches/1.7.x/include/arch/netware/apr_arch_threadproc.h Fri Dec
> 4 18:15:55 2020
> @@ -36,6 +36,7 @@ struct apr_thread_t {
> void *data;
> apr_thread_start_t func;
> apr_status_t exitval;
> +int detached;
> };
>
> struct apr_threadattr_t {
>
> Modified: apr/apr/branches/1.7.x/include/arch/unix/apr_arch_threadproc.h
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/include/arch/unix/apr_arch_threadproc.h?rev=1884103=1884102=1884103=diff
> ==
> --- apr/apr/branches/1.7.x/include/arch/unix/apr_arch_threadproc.h (original)
> +++
Re: svn commit: r1863234 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c
This is the first commit which appeared to break APR in such a way that code compiled against apr 1.7.1 would be unable to run against apr 1.7.0 binaries. Thoughts, rjung? Are you willing to revert? This would persist on apr 1.8.x for those interested in this new feature. On Wed, Jul 17, 2019 at 2:04 PM wrote: > > Author: rjung > Date: Wed Jul 17 19:04:43 2019 > New Revision: 1863234 > > URL: http://svn.apache.org/viewvc?rev=1863234=rev > Log: > Add empty stubs for APR pool functions, that are > only needed when APR_POOL_DEBUG is defined, > but can be aor should be called from app code. > > Providing stubs allows the app code to stay the > same when running with or without debugging APR > lib (no need for app recompilation). > > Backport of r1863217 from trunk. > > Modified: > apr/apr/branches/1.7.x/ (props changed) > apr/apr/branches/1.7.x/include/apr_pools.h > apr/apr/branches/1.7.x/memory/unix/apr_pools.c > > Propchange: apr/apr/branches/1.7.x/ > -- > --- svn:mergeinfo (original) > +++ svn:mergeinfo Wed Jul 17 19:04:43 2019 > @@ -1,4 +1,4 @@ > /apr/apr/branches/1.4.x:1003369,1101301 > -/apr/apr/trunk:733052,739635,741862,741866-741867,741869,741871,745763-745764,746310,747990,748080,748361,748371,748565,74,748902,748988,749810,760443,767895,775683,782838,783398,783958,784633,784773,788588,789050,793192-793193,794118,794485,795267,799497,800627,809745,809854,810472,811455,813063,821306,829490,831641,832904,835607,888669,892028,892159,892435,892909,896382,896653,899905,901088,902077,902090,908427,910419,910597,917819,917837-917838,923311,923320,925965,929796,930508,931973,932585,951771,960665,960671,979891,983618,989450,990435,1003338,100,107,1055657,1072165,1078845,1081462,1081495,1082177,1083038,1083242,1084662,1086695,1088023,1089031,1089129,1089438,1099348,1103310,1183683,1183685-1183686,1183688,1183693,1183698,1213382,1235047,1236970,1237078,1237507,1240472,1340286,1340288,1340470,1341193,1341196,1343233,1343243,1367050,1368819,1370494,1372018,1372022,1372093,1372849,1376957,1384764,1389077,1400200,1402868,1405985,1406690,1420106,1420109,1425356,142 > > 8809,1438940,1438957-1438959,1442903,1449568,1456418,1459994,1460179-1460180,1460184,1460241,1460399,1460405,1462738,1462813,1470186,1470348,1475509,1478905,1480067,1481186,1481262,1481265,1484271,1487796,1489517,1496407,1502804,1510354,1516261,1523384,1523479,1523484,1523505,1523521,1523604,1523613,1523615,1523844-1523845,1523853,1524014,1524031,1528797,1528809,1529488,1529495,1529515,1529521,1529668,1530786,1530800,1530988,1531554,1531768,1531884,1532022,1533104,1533111,1533979,1534882,1535027,1535157,1536744,1538171,1539374,1539389,1539455,1539603,1541054,1541061,1541486,1541655,1541666,1541744,1542601,1542779,1543033,1543056,1548575,1550907,1551650,1551659,1558905,1559382,1559873,1559975,1561040,1561260,1561265,1561321,1561347,1561356,1561361,1561394,1561555,1571894,1575509,1578420,1587045,1587063,1587543,1587545,1588878,1588937,1589982,1593611,1593614-1593615,1593680,1594684,1594708,1595549,1597797,1597803,1604590,1604596,1604598,1605104,1610854,1611023,1611107,160,167, > > 1611120,1611125,1611184,1611193,1611466,1611515,1611517,1625173,1626564,1634615,1642159,1648830,1664406,1664447,1664451,1664471,1664769-1664770,1664775,1664904,1664911,1664958,1666341,1666411,1666458,111,1667420-1667421,1667423,1667900-1667901,1667903,1667914-1667916,1667962,1669077,1671292,1671329,1671356,1671386,1671389,1671513-1671514,1671957,1672354,1672366,1672495,1672575,1674566,1675644,1675656,1675668,1675967,1675970,1675982,1676013,1683521,1685929,1696140,1696767,1722547,1722557,1726928,1727020,1727160,1727175,1727199,1728957,1732582,1733451,1733594,1733694,1733706,1733708,1733775,1734816,1736552,1738791,1738925,1750374,1755709,1755740,1755746,1755758,1755954,1761279,1762326,1774712,1774973,1775069,1776994,1776998,1788334,1788337,1788929,1789947,1789998,1790045,1790200,1790296,1790302-1790304,1790330-1790331,1790436,1790439,1790444,1790446,1790488,1790521,1790523,1790569,1790632,1791598,1791718,1791728,1792620-1792622,1792625,1792961,1792963,1794266,1797415,1798105,18053 > > 80,1808039,1808836,1808910,1809649,1810452,1813286,1813330,1814239-1814240,1814326,1814329,1814331,1816527,1816628,1817485,1819857-1819858,1819860-1819861,1819934-1819935,1820080,1820755,1822357,1827534,1832203,1832691,1832985,1834253,1834494,1834541,1836235,1839068,1839493,1839622,1839769,1840372,1841078,1846806,1850087,1850095,1851541-1851542,1854123,1855049,1855347,1855443-1855444,1855839-1855840,1855855,1855864,1855867,1855877,1855949,1856022,1856042-1856043,1856046,1856050,1856063,1856089,1856096,1856178,1856192,1856196,1856756,1858596,1863205 >
