Asterisk
  1. Asterisk
  2. ASTERISK-15719

glibc 2.11.1 causes asterisk to not start due to return code from dlclose

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      16934
    • Regression:
      No

      Description

      On Fedora-12, with its current glibc (glibc-2.11.1-1), asterisk fails to start up when it loads any module.

      In main/loader.c there are 4 instances of the following code:
      while (!dlclose(lib));

      dlclose() in glibc-2.11.1-1 returns 0 (SUCCESS) even if the library has already been closed, and consequently the while loop never terminates.

      On Fedora-11 (with glibc-2.10.2-1) and Fedora-13 (with glibc-2-11-90.14), dlclose() returns -1 if the library is already closed, and so the problem does not occur.

      This issue certain occurs with asterisk version 1.6.1.12 and later (including current SVN head).

                • ADDITIONAL INFORMATION ******

      I reported this as a bug in glibc (see https://bugzilla.redhat.com/show_bug.cgi?id=569060 ), and the response was that this is undefined behaviour.

      I have reported the problem against Asterisk in Fedora, (see https://bugzilla.redhat.com/show_bug.cgi?id=569384 ), and have been asked to report it upstream. There is an ugly patch attached to that bug report as a workaround to the problem.

        Issue Links

          Activity

          Hide
          Leif Madsen added a comment -

          Ya, I'm not 100% sure what we'll do here. If it works fine in an older and a newer version of glibc, I'd suppose I'd recommend avoiding that version

          Show
          Leif Madsen added a comment - Ya, I'm not 100% sure what we'll do here. If it works fine in an older and a newer version of glibc, I'd suppose I'd recommend avoiding that version
          Hide
          Quentin Armitage added a comment -

          The concern must be that if the behaviour of dlclose() is undefined if the library is already closed, then the behaviour of the while (dlclose(lib)); loop is undefined, and may break again in the future.

          Is it possible to get a definitive answer on the behaviour of dlclose() in this circumstance, since if it is undefined, then Asterisk is relying on undefined behaviour, which could cause problems for both new ports, and for future upgrades.

          Show
          Quentin Armitage added a comment - The concern must be that if the behaviour of dlclose() is undefined if the library is already closed, then the behaviour of the while (dlclose(lib)); loop is undefined, and may break again in the future. Is it possible to get a definitive answer on the behaviour of dlclose() in this circumstance, since if it is undefined, then Asterisk is relying on undefined behaviour, which could cause problems for both new ports, and for future upgrades.
          Hide
          Leif Madsen added a comment -

          After discussion, this is definitely something we'll need to deal with as Asterisk is relying on undefined behaviour.

          Show
          Leif Madsen added a comment - After discussion, this is definitely something we'll need to deal with as Asterisk is relying on undefined behaviour.
          Hide
          Rusty Newton added a comment -

          Appears to be duplicated by ASTERISK-21050 which has an attached patch.

          Show
          Rusty Newton added a comment - Appears to be duplicated by ASTERISK-21050 which has an attached patch.
          Hide
          Matt Jordan added a comment -

          This was fixed in r402287 in 1.8+.

          Show
          Matt Jordan added a comment - This was fixed in r402287 in 1.8+.

            People

            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development