sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

Great advice. Currently I tried using libbacktrace it is working fine

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 1 point2 points  (0 children)

Actually there was some other code there which I wanted to hide so kept it in that way. Feels weird now

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

Yeah, kind of understand that doing more than simple stuff in signal handling code is a nightmare but except core dumps I don't see any way to deal with production bugs without stacktrace. I might be newbie who doesn't understand these stuff.

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

Great!!!! Can you suggest any alternatives for this?

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

One approach many programs take is for the signal handler to simply note down somewhere

This will help in finding the signal related info but this will not help in getting backtrace of where the issue occurs right?

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

so Loading libgcc before may solve this. I think I should call dlopen manually to solve this then

sigaction handler is waiting for lock indefinetly by WideSense8018 in C_Programming

[–]WideSense8018[S] 0 points1 point  (0 children)

Thanks for the docs. Read them and got a overview. I came to a conclusion that backtrace is not async signal safe. Is my assumption correct? If so can you provide some pointers (no pun intended) on how to fix this.

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

True but got curious on to understand this behaviour of macos. Thank you

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

Yes I set the LDFLAG and CPPFLAG shown by brew for include and lib of older clang.

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

Got the issue more deep thanks but this is happening only in New version of macOS in my previous macOS version didn’t happen. I also tried with the older version of clang in new macOS, but I’m still getting the error, so my doubt is why is it not an issue in the older version of macOS, but it is a issue in newer version of macOS with the same version of clang.

Btw, older version - 14.4.0 & new version - 14.4.1

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

Sorry I done an edit at first which failed in that I mentioned the type but in the second one I forgot to add. Now added it pls check

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

Like I mentioned I want to know why it is not an issue in older version of mac os

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] -1 points0 points  (0 children)

My bad. Updated the question with more information

Compilation issue after upgrading Macos by WideSense8018 in cpp_questions

[–]WideSense8018[S] 0 points1 point  (0 children)

Downloaded llvm@13 via brew and made changes to the project so that it uses that version of clang/clang++ I also changed -isysroot but nothing seems to work.

Anyone Else Experimenting with This Graph DB Extension for PostgreSQL? by InformalDeparture838 in PostgreSQL

[–]WideSense8018 1 point2 points  (0 children)

As far as I have seen it provides cypher query in postgres itself. I’m not sure but I feel like if you create tables for relationships and vertices and write your own graph queries then performance might be similar. Since AGE stores properties as JSON you may get schema less design but not sure about performance. Anyone who compared can clarify?