I working with Orbeon XForms 4.7 on eXist-db 2.2. We've always had session problems where a session would expire in eXist-db after a given point in time, but where Orbeon retains a session token and 'thinks' it is still logged on. This may or may not be at the heart of what I see in the logging:
2016-11-07 15:06:27,643 INFO ProcessorService - /xforms-server - Received request
2016-11-07 15:06:27,650 INFO ProcessorService - /xforms-server - Timing: 7
2016-11-07 15:06:29,368 INFO ProcessorService - /xforms-server - Received request
2016-11-07 15:06:29,372 ERROR XFormsServer - Unable to retrieve XForms engine state. Please reload the current page. Note that you will lose any unsaved changes. {}
2016-11-07 15:06:29,372 INFO ProcessorService - /xforms-server - Timing: 4
2016-11-07 15:06:29,373 ERROR ProcessorService -
+----------------------------------------------------------------------------------------------------------------------+
|An Error has Occurred |
|----------------------------------------------------------------------------------------------------------------------|
|Unable to retrieve XForms engine state. Please reload the current page. Note that you will lose any unsaved changes. |
|----------------------------------------------------------------------------------------------------------------------|
|Application Call Stack |
|----------------------------------------------------------------------------------------------------------------------|
|oxf:/config/prologue-servlet.xpl |executing processor | 36|
|······················································································································|
|element=<p:processor name="oxf:pipeline">[...]</p:processor> |
|name ={http://www.orbeon.com/oxf/processors}pipeline |
|----------------------------------------------------------------------------------------------------------------------|
|oxf:/ops/xforms/xforms-server.xpl |reading processor output | 43|
|······················································································································|
|element=<p:output name="response" id="xforms-response"/> |
|name =response |
|id =xforms-response |
|----------------------------------------------------------------------------------------------------------------------|
|----------------------------------------------------------------------------------------------------------------------|
|Exception: org.orbeon.oxf.common.OXFException |
|----------------------------------------------------------------------------------------------------------------------|
|org.orbeon.oxf.xforms.state.XFormsStateManager |createDocumentFromStore |XFormsStateManager.java | 489|
|org.orbeon.oxf.xforms.state.XFormsStateManager |findOrRestoreDocument |XFormsStateManager.java | 448|
|org.orbeon.oxf.xforms.state.XFormsStateManager |beforeUpdate |XFormsStateManager.java | 328|
|org.orbeon.oxf.xforms.processor.XFormsServer |doIt |XFormsServer.java | 169|
|org.orbeon.oxf.xforms.processor.XFormsServer |access$000 |XFormsServer.java | 59|
|org.orbeon.oxf.xforms.processor.XFormsServer$1 |readImpl |XFormsServer.java | 85|
|essor.impl.ProcessorOutputImpl$TopLevelOutputFilter|read |ProcessorOutputImpl.java | 257|
|org.orbeon.oxf.processor.impl.ProcessorOutputImpl |read |ProcessorOutputImpl.java | 394|
|----------------------------------------------------------------------------------------------------------------------|
|Exception: org.orbeon.oxf.common.ValidationException |
|----------------------------------------------------------------------------------------------------------------------|
|org.orbeon.oxf.common.OrbeonLocationException$ |wrapException |OrbeonLocationException.scala | 60|
|org.orbeon.oxf.common.OrbeonLocationException |wrapException |OrbeonLocationException.scala | |
This error comes up every such and so seconds. There is no mention what XForms triggers it, so a targeted search is out of the question.
Does anyone know how to interpret this error and possibly how to prevent it? Note that there's no error at the user side at all, and everything appears to work fine. This is purely server side.
Related
I'm retrieving a frame from CSI camera using Argus (EGLStream).
Since my application can be optimized via CUDA, I decided to use cuEGLStream to bypass copying data to device(GPU) from host(CPU).
...
cv::cuda::GpuMat gpuMat;
gpuMat.create(cv::Size(640, 480), CV_8UC4);
// Convert CUeglFrame and save to gpuMat(BGR)
status = nppiNV21ToBGR_8u_P2C4R_Ctx((const Npp8u * const*)m_frame.frame.pPitch[0],
m_frame.pitch,
(Npp8u *)gpuMat.cudaPtr(),
gpuMat.step,
in_size,
nppctx);
....
// Fail to release eglFrame
CUresult r = cuEGLStreamConsumerReleaseFrame(&m_connection, m_resource, &m_stream);
========LOOP STARTED========
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] cudaStreamCreate
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] cuEGLStreamConsumerAcquireFrame!
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] cuGraphicsResourceGetMappedEglFrame
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] m_connection: 0x7f60463b90
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] m_resource: 0x7f60479420
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [GOOD] m_stream: 0x7f60463080
ScopedCudaEGLStreamFrameAcquire::generateHistogram | [GOOD] nppSetStream
ScopedCudaEGLStreamFrameAcquire::generateHistogram | [GOOD] nppGetStreamContext
ScopedCudaEGLStreamFrameAcquire::generateHistogram | [GOOD] cudaStreamSynchronize
========LOOP FINISHED========
ScopedCudaEGLStreamFrameAcquire::~ScopedCudaEGLStreamFrameAcquire | [BAD] cuEGLStreamConsumerReleaseFrame! <- Crashes
ScopedCudaEGLStreamFrameAcquire::~ScopedCudaEGLStreamFrameAcquire | [BAD] m_connection: 0x7f60463b90
ScopedCudaEGLStreamFrameAcquire::~ScopedCudaEGLStreamFrameAcquire | [BAD] m_resource: 0x7f60479420
ScopedCudaEGLStreamFrameAcquire::~ScopedCudaEGLStreamFrameAcquire | [BAD] m_stream: 0x7f60463080
ScopedCudaEGLStreamFrameAcquire::~ScopedCudaEGLStreamFrameAcquire | [BAD] cuEGLStreamConsumerReleaseFrame unspecified launch failure!
========LOOP STARTED========
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [BAD] cudaStreamCreate
ScopedCudaEGLStreamFrameAcquire::ScopedCudaEGLStreamFrameAcquire | [BAD] cuGraphicsResourceGetMappedEglFrame!
CONSUMER: No more frames. Cleaning up.
CONSUMER: Done.
PRODUCER: Captures complete, disconnecting producer.
PRODUCER: Done -- exiting.
The problem is, the conversion works, but it fails to release eglFrame at the end.
(According to the document, the frame must be released back to eglStream)
When nppiNV21ToBGR_8u_P2C4R_Ctx() is commented out, the program works fine.
Any help will be appreciated!
I have a very simple script where I am trying to fill a username field in a website using "fillField" in Appium but I get this error "locator.stringify is not a function". I am not able to figure out what is the issue. Any help is appreciated. Here is the verbose output-
[1] Starting recording promises
Emitted | suite.before ([object Object])
test something
Emitted | test.before ([object Object])
Emitted | test.start ([object Object])
Emitted | step.before (I am on page "https://xxxxxxxxx.com/#login")
Emitted | step.after (I am on page "https://xxxxxxxxx.com/#login")
Emitted | step.before (I wait 6)
Emitted | step.after (I wait 6)
Emitted | step.before (I fill field "username", "hello#world.com")
Emitted | step.after (I fill field "username", "hello#world.com")
Emitted | step.start (I am on page "https://xxxxxxx.com/#login")
I am on page "https://xxxxxxxxxxx.com/#login"
Emitted | step.passed (I am on page "https://xxxxxxx.com/#login")
Emitted | step.finish (I am on page "https://xxxxxxxx.com/#login")
Emitted | step.start (I wait 6)
I wait 6
Emitted | step.passed (I wait 6)
Emitted | step.finish (I wait 6)
Emitted | step.start (I fill field "username", "hello#world.com")
I fill field "username", "hello#world.com"
[1] Error | TypeError: locator.stringify is not a function
Emitted | step.failed (I fill field "username", "hello#world.com")
Emitted | step.finish (I fill field "username", "hello#world.com")
[1] Error | TypeError: locator.stringify is not a function
[1] Starting <teardown> session
Emitted | test.failed ([object Object])
Emitted | test.finish ([object Object])
[1] <teardown> Stopping recording promises
› <screenshotOnFail> Test failed, saving screenshot
› Screenshot has been saved to /Users/qa-engg/Documents/codeceptJS/appium/output/test_something.failed.png
✖ FAILED in 9740ms
[2] Starting recording promises
Emitted | test.after ([object Object])
Emitted | suite.after ([object Object])
-- FAILURES:
1) IP mobile
test something:
locator.stringify is not a function
It looks like you found a bug, made in Dec, 2017.
Soon, fix will be made.
As workaround, use different locators, not just string "username".
CSS, Xpath, Strict locator for example.
#Evgeny - Thanks for your response. I was finally able to zero down the problem to the installation of webdriverio. I had both global and local installations. I uninstalled everything and just did a local install which seems to have fixed the issue.
I'm running into some odd behavior when trying to setup an ActionFixture test using Fitnesse (with FitSharp as the test runner)
When creating an actionFixture I'll get an error that the class (Namespace.TestClassName in example below) cannot be found. If I create a wiki page for it the test will work.
| actionFixture |
| start | Namespace.TestClassName |
Is it required to have a page for each class? If so can I reference the same page for all tests (different location in hierarchy)?
Sorry for the naive question, sure I'm missing something simple here.
Simple error on my part;
Needed to enclose the class name as shown below
| actionFixture |
| start | !-Namespace.TestClassName-! |
...or simply don't write the name as a wikiword;
| actionFixture |
| start | namespace.testClassName |
I'm using CircleCI to check for security issues and this is cropping up as an error, though I'm not sure that it is.
This is the line of code that is causing one of the scripting errors:
= link_to t(:delete), main_app.board_comment_path(#board, comment), method: :delete
Is this a valid security issue? Is there any way for me to make Brakeman accept these parameters as safe? I read up on --url-safe-methods but I couldn't figure out a way to make it work.
Used this link as a guide https://github.com/presidentbeef/brakeman/pull/45
Running bundle exec brakeman -A -q --exit-on-warn, this is the error report:
+BRAKEMAN REPORT+
Application path: ****
Rails version: 4.2.2
Brakeman version: 3.0.4
Started at 2015-06-26 14:10:14 -0700
Duration: 1.8311 seconds
Checks run: BasicAuth, ContentTag, CreateWith, CrossSiteScripting, DefaultRoutes, Deserialize, DetailedExceptions, DigestDoS, EscapeFunction, Evaluation, Execute, FileAccess, FileDisclosure, FilterSkipping, ForgerySetting, HeaderDoS, I18nXSS, JRubyXML, JSONEncoding, JSONParsing, LinkTo, LinkToHref, MailTo, MassAssignment, ModelAttrAccessible, ModelAttributes, ModelSerialize, NestedAttributes, NumberToCurrency, QuoteTableName, Redirect, RegexDoS, Render, RenderDoS, RenderInline, ResponseSplitting, SQL, SQLCVEs, SSLVerify, SafeBufferManipulation, SanitizeMethods, SelectTag, SelectVulnerability, Send, SendFile, SessionSettings, SimpleFormat, SingleQuotes, SkipBeforeFilter, StripTags, SymbolDoS, SymbolDoSCVE, TranslateBug, UnsafeReflection, UnscopedFind, ValidationRegex, WithoutProtection, XMLDoS, YAMLParsing
+SUMMARY+
+-------------------+-------+
| Scanned/Reported | Total |
+-------------------+-------+
| Controllers | 23 |
| Models | 9 |
| Templates | 53 |
| Errors | 0 |
| Security Warnings | 2 (0) |
+-------------------+-------+
+----------------------+-------+
| Warning Type | Total |
+----------------------+-------+
| Cross Site Scripting | 2 |
+----------------------+-------+
View Warnings:
+------------+------------------------------------------------------------------+----------------------+-------------------->>
| Confidence | Template | Warning Type | Message >>
+------------+------------------------------------------------------------------+----------------------+-------------------->>
| Medium | boards/show (BoardsController#show) | Cross Site Scripting | Unsafe parameter va>>
| Medium | boards/show (BoardsController#show) | Cross Site Scripting | Unsafe parameter va>>
+------------+------------------------------------------------------------------+----------------------+-------------------->>
This is (almost certainly) a false positive, assuming board_comment_path returns a path.
The reason Brakeman warns about URLs in link_to is because it is possible to set URLs like javascript:dangerous_stuff_here(). A common example would be user profiles linking to a user's website.
--url-safe-methods only applies to methods wrapping input to link_to. For example, link_to 'stuff', safe_url(some_input).
However, after https://github.com/presidentbeef/brakeman/pull/674 Brakeman will stop warning about path helpers in URLs and also expand --safe-methods/--url-safe-methods to match all types of methods.
I have an application that requests data from a database triggered by a timer on a form. If there is an error (the connection to the database is lost), I sometimes I get the expected exception (EIBO_ISCError) and sometimes I get an access violation in RtlLeaveCriticalSection of ntdll.dll. Here is the corresponing Eurekalog stack:
------------------------------------------------------------------------------------------------------
|Adresse |Modul |Unit |Klasse |Prozedur/Methode |Zeile |
------------------------------------------------------------------------------------------------------
|Laufender Thread: ID=1320; Priorität=0; Klasse=; [Haupt Thread] |
|----------------------------------------------------------------------------------------------------|
|76FD2280|ntdll.dll | | |RtlLeaveCriticalSection | |
|76FDE0ED|ntdll.dll | | |RtlAllocateHeap | |
|76FE6CC5|ntdll.dll | | |LdrUnlockLoaderLock | |
|7552EF19|KERNELBASE.dll| | |VirtualQueryEx | |
|7552EF02|KERNELBASE.dll| | |VirtualQueryEx | |
|7552EFE6|KERNELBASE.dll| | |VirtualQuery | |
|76FC012E|ntdll.dll | | |KiUserExceptionDispatcher | |
|0069D997|Program.exe |IBODataset.pas |TIBOInternalDataset|DoHandleError |8407[23] |
|0063B3F7|Program.exe |IB_Components.pas |TIB_Session |DoHandleError |13181[2] |
|0068B36C|Program.exe |IB_Session.pas |TIB_SessionBase |HandleException |1442[58] |
|0068B03C|Program.exe |IB_Session.pas |TIB_SessionBase |HandleException |1384[0] |
|0064EE74|Program.exe |IB_Components.pas |TIB_Statement |API_Execute |22927[14]|
|0064EE10|Program.exe |IB_Components.pas |TIB_Statement |API_Execute |22913[0] |
|00655D1D|Program.exe |IB_Components.pas |TIB_Dataset |SysExecSelect |26432[1] |
|0064DA60|Program.exe |IB_Components.pas |TIB_Statement |SysExecStatement |22259[9] |
|0064D7A1|Program.exe |IB_Components.pas |TIB_Statement |SysExecute |22173[12]|
|0064D708|Program.exe |IB_Components.pas |TIB_Statement |SysExecute |22161[0] |
|00655A9F|Program.exe |IB_Components.pas |TIB_Dataset |SysExecute |26373[7] |
|00655210|Program.exe |IB_Components.pas |TIB_Dataset |SysOpen |26160[23]|
|006550F8|Program.exe |IB_Components.pas |TIB_Dataset |SysOpen |26137[0] |
|006994E5|Program.exe |IBODataset.pas |TIBODataset |DoBeforeOpen |6312[17] |
|0061FBEA|Program.exe |mvdb.pas |TImvDatabase |QueryRun |1393[10] |
...
|00B1D440|Program.exe |StartDialogForm.pas|TFormStartDialog |UpdateStartBar |494[0] |
|00B1D4C3|Program.exe |StartDialogForm.pas|TFormStartDialog |TimerExBarTimer |521[6] |
|76667BC5|USER32.dll | | |DispatchMessageA | |
|76667BBB|USER32.dll | | |DispatchMessageA | |
|00BF1178|Program.exe |Program.dpr | | |884[399] |
------------------------------------------------------------------------------------------------------
The code, which is executed, is nothing special. It boils down to:
qry := TIBOQuery.Create(nil); //IBObjects
qry.SQL := 'SELECT COUNT(IDX) FROM TABLE';
qry.Prepare;
when creating the form and
qry.Open; //<-- Exception
TotalCount := qry.Fields[0].AsVariant;
qry.Close;
in the OnTimer event of the MDI form.
The code line in IBObjects that is called in DoHandleError is
raise EIBO_ISCError.CreateISC( ... );
The underlaying exception is likely to be caused by a lost database connection in qry.Open. What I want to know is, which circumstances (read defects in my code) can lead to the behaviour, that sometimes this exception is handled as expected (EIBO_ISCError in Eurekalog) and sometimes the same exception leads to an access violation in RtlLeaveCriticalSection.
It looks like you have heap corruption. Somewhere, your program has written to memory that you're not supposed to write to.
That might mean you've written to a critical-section data structure belonging to the heap, but it might mean you've written somewhere else that caused the memory manager to think there's a critical-section object where there really isn't one.
The stack trace suggests you're still getting the usual exception you expected to get, but in attempting to handle that exception, something goes wrong.
You could try using the debugger to inspect other memory near where the invalid read occurs. See whether there are any strings or numbers you recognize from your program. They could indicate which section of code is writing where it shouldn't.
From the comments, for reference:
The cause of this access violation was, that I freed an exception that occured while handling an other exception (like originally suggested here).
Citation from the comments:
you should never free an exception, ever
The exception was handled normally if during the handling of the original exception no other exception occured. If an other exception occured I got the access violation.