Trojan horse reported by avira free-av during the setup (installer) #1
Comments
|
Other users have reported this too, perhaps you should talk to Avira? |
|
an explanation what could raise the detection could be made by the one who created the setup package. At least a guess would help so one could dismiss the report by avira. I'm not interested in talking to avira; it's you who provide the software and it's up to you if you want to keep a certain group of users running avira on windows happy or not. I don't care too much; I simply don't use the software then; it's easy for me :). Have a nice weekend. |
|
This issue vanishes as soon as "koch" is not compiled in release mode. I don't know any other way to fix it. It really seems some heuristic in Avira is wrong. However, it's easy to package another koch binary in the next version. |
This was referenced Apr 30, 2015
singularperturbation
pushed a commit
to singularperturbation/Nim
that referenced
this issue
Jul 3, 2015
osLastError() and whitespace
ThomasTJdev
added a commit
to ThomasTJdev/Nim
that referenced
this issue
Jan 19, 2019
DongyunLee
pushed a commit
to nim-lang-cn/Nim
that referenced
this issue
Nov 18, 2019
krux02
pushed a commit
to krux02/Nim
that referenced
this issue
Jan 11, 2022
* remove noise/failing tests * fix ssl, and add converter tests * tests pass on the c target -- a decent start
ci4ic4
added a commit
to ci4ic4/Nim
that referenced
this issue
Dec 30, 2022
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () nim-lang#1 0x00000000004897b2 in threadVarAlloc__system_2162 () nim-lang#2 0x000000000048980e in initThreadVarsEmulation () nim-lang#3 0x0000000000489848 in PreMain () nim-lang#4 0x000000000048986a in NimMain () nim-lang#5 0x00000000004898a9 in main () I can't speak about the other BSDs.
Merged
Araq
pushed a commit
that referenced
this issue
Jan 2, 2023
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () #1 0x00000000004897b2 in threadVarAlloc__system_2162 () #2 0x000000000048980e in initThreadVarsEmulation () #3 0x0000000000489848 in PreMain () #4 0x000000000048986a in NimMain () #5 0x00000000004898a9 in main () I can't speak about the other BSDs.
narimiran
pushed a commit
that referenced
this issue
Jan 2, 2023
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () #1 0x00000000004897b2 in threadVarAlloc__system_2162 () #2 0x000000000048980e in initThreadVarsEmulation () #3 0x0000000000489848 in PreMain () #4 0x000000000048986a in NimMain () #5 0x00000000004898a9 in main () I can't speak about the other BSDs. (cherry picked from commit e9ed090)
capocasa
pushed a commit
to capocasa/Nim
that referenced
this issue
Mar 31, 2023
tlsEmulation:on under NetBSD-10Beta and NetBSD-current produces an executable which crashes immediately as follows: Core was generated by `koch'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000047b4c2 in nimZeroMem () (gdb) bt #0 0x000000000047b4c2 in nimZeroMem () nim-lang#1 0x00000000004897b2 in threadVarAlloc__system_2162 () nim-lang#2 0x000000000048980e in initThreadVarsEmulation () nim-lang#3 0x0000000000489848 in PreMain () nim-lang#4 0x000000000048986a in NimMain () nim-lang#5 0x00000000004898a9 in main () I can't speak about the other BSDs.
Clyybber
pushed a commit
to Clyybber/Nim
that referenced
this issue
Sep 16, 2023
Summary ======= This commit introduces internal signatures for macros, removing conditional logic from parameter symbol handling and generally moving the details of how macro parameters work out of `vmgen` and more into a single place in `sem`. As two side-effect of the above: - inspecting parameter types from a macro's header (via, for example, `typeof`) now yields the types as specified, instead of as `NimNode` - the types (or values, in case of `static[T]`) passed to a macro's generic parameters can now be inspected by the macro Details ======= The symbols belonging to macro parameters were previously replaced with new ones that used either `NimNode` or, in the case of `static[T]`, the base type as the type, prior to adding them to the symbol table. Replacing the symbols at some point is necessary in order for semantic analysis inside the macro body to view them as the correct type, but the previous implementation had two issues: 1. the parameters were only visible as `NimNode` to other types or expressions referencing them 2. the symbols were freestanding. They weren't registered anywhere, meaning that it was not possible to, for example, map all parameter symbols via their ID to some other entity To fix both issues and in order for the implementation to be less scattered, a different approach is now used. Macro parameter handling is moved out of routine header analysis into `semMacroDef` (fixing nim-lang#1). This allows for a more flexible implementation (more contextual information is available) and also reduces the amount of context required by `addParam`, etc. So that they can be later queried, the created internal symbols are added as parameters to a dedicated `tyProc` type that represents the macro's internal signature, which is then stored as part of the macro's symbol. Changes ------- - remove macro parameter handling from `addParamOrResult` and `addResult` - add a dedicated branch for `skMacro` to `TSym` and adjust the places depending on the previous layout - create the internal symbols for macro parameters in `semMacroDef`, where they're also used to populate the internal signature - add a `transformBody` variant that doesn't query nor updates the symbols `transformBody` field - change `vmgen` to consider the macros internal signature, making the previously used workarounds obsolete - rewrite `getAst(macro(a, b, c))` during `mirgen`, slightly simplifying the related logic in `vmgen` - remove the now unused `adVmGenBadExpandToAstCallExprRequired` diagnostic
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Filename: nimrod_0.8.10.exe
affected file: koch.exe
TR/ATRAPS.Gen
OS: Windows XP Pro SP3
The text was updated successfully, but these errors were encountered: