Opened 8 years ago

Closed 8 years ago

#1289 closed defect (fixed)

nested dlopen through python failure

Reported by: jelte Owned by: jelte
Priority: very high Milestone: Sprint-20111011
Component: data source Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: High
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I have discovered why we still have the problem of exceptions that aren't recognized on some systems (though I do not know *why* it happens on some systems and not others). The solution appears to be to also let python itself load the modules that load other modules (in our case, the datasrc wrapper module) with RTLD_GLOBAL.

I will put a fix for this in the branch for this ticket

Subtickets

Change History (6)

comment:1 Changed 8 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from new to reviewing

comment:2 Changed 8 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:3 Changed 8 years ago by vorner

  • Owner changed from vorner to jelte

Hello

What I read about the global flag, it manipulates the global symbol table. This indeed might help with the exceptions, but I worry little bit about if it solves the whole problem.

What if two libraries are loaded, each one providing it's copy of the exception. The second one loaded probably overwrites the symbol table after the first one. Then the first one would still not work.

But as it breaks our build bots and generally annoys, let me propose this. Put the fix into master, decrease the priority and leave it open (and put it into next sprint, maybe?). Then we would need to implement a test where we would load two libraries at once and see if they both work well. Do you think it would be OK? Or is pushing the fix first too much against the policies?

Thanks

comment:4 Changed 8 years ago by jelte

  • Owner changed from jelte to vorner

i went ahead and implemented a simple test, please check

perhaps a future test is to add a 'dummy' module that intentionally tries to break things.

comment:5 Changed 8 years ago by vorner

  • Owner changed from vorner to jelte

OK, thanks for the test. I believe we can merge this.

The bad module is indeed a good idea, we want to have reasonable error handling to make programming for Bind10 easy. But I'd say it should be a different ticket.

Thanks

comment:6 Changed 8 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

ok, thanks, merged.

Note: See TracTickets for help on using tickets.